When will Version 6 be Released?

Found this on the interwebs:
“Version: (6.0.0-rc1-dev-86-g887ee4693), release build”
It is already tagged as “RC1”?

Cern estimates it “600 hours of expert development, this might become a reality!”
From: https://givetokicad.web.cern.ch/

Then, there is the video for the ‘KiCad v6 Donation Campaign’ and the two developers look a bit excited about making an attempt to complete this next version fairly quickly.

https://youtu.be/uhcMGQ32Xw0

600 hours for one person working 40 hours a week is 15 weeks. Then, four people working is just short of 4 weeks.

How long was the transition time from V5RC1 designation to the stable release?

It does seem to me that creating this post may well generate some criticisms since the V5 release was only yesterday. It is my hope that some will take this topic seriously and look at the clues and provide their own honest feedback about what they think the next step looks like in the development of KiCad.

Thanks!

About two years I suspect as eeschema is getting redone.
The 5.1 that works properly on modern Linux GTX3 is more interesting for now.

1 Like

I don’t think the 600 hours are the estimate for getting v6. This is more the goal for the fundraiser that tries to use the hype around the v5 release.

As @davidsrsb wrote two years is a more realistic timeframe for getting all of eeschema redone with the new file format plus opengl/cairo canvases.

My friend is a Linux user, and he tells me it might get even more interesting when the next generation of “GTX” gets implemented (and I forget the name of it, but it’s not GTX4).

From the videos I have seen, I’m thinking Eeschema may already be more complete then has been reported; there is only 1 layer per item after all.

2 years is 4,160 hours of development time for one person. Do think Cern is that dishonest?

On Edit: Dorked up the clicking on the calculator.

There is a lot more than the new eeschema too, some of the possible extras are:

Pad stack - this impacts DRC, placement and the Push and Shove router.
BOM build options
Design rules by net/zone
Teardrops
Arc tracks

Don’t forget the new file format. As far as i can tell there is not even a final decision on how it will look like. (There are still discussions about the details. Especially about what will be included in v6 and what will be pushed back to v7)

Okay, you Two.

I pulled out my card and donated in an attempt to make it happen in less than two years.

Confirm your own donation and I will up mine one notch; matching one level higher than mine for both of yours (2 or none).

It is a little amazing to me that despite all the time here you are still not aware of the KiCad development cycle.

If you look at the v5 thread, you can see my prediction for an Aug 2018 release for v5 was off by a week or so. This was not based on any magic insight, merely the observation that the past is often a good guide to the future. I extrapolated from the v4 release cycle.

Software is notoriously hard to predict and/or manage. 50% of projects fail to deliver at all. 80% run over time or budget. Project plans are 90% guesswork and luck. There is a great book called The Mythical Man-Month written many years ago but the advice is still sound. Few project managers have heard of it, let alone read it.

I am in progress meetings every week, it is really quite depressing watching the same mistakes being made over and over again. Project managers seem to be picked based on enthusiasm, rather than any skill or knowledge.

Anyway, software is primarily a task of organising information. We don’t have good ways to predict it, simulate it or automate it. It’s a bit like Minecraft, except there are no real world rules and infinite dimensions. Well, there are some rules, delivery always get later, never earlier. I am still pondering that one, it’s like there is a time ratchet. Unexpected events always make a slip.

I have been working in software over 30 years, still no one has any real clue how to make software development predictable and deterministic. It is still very much a craft exercise.

So I am rather sceptical that throwing money or bodies at a new version will help much. The killer is tasks that can not be overlapped and latency in those. To significantly help with that, there would need to be a full time project manager, architect and test team.

There is also the paradox that if you make you development more effective, the temptation is to use that to add more features, rather than reduce the release time. The release cycle has a lot of overhead, KiCad takes at least 6 months from feature freeze to release. So you don’t really want to do 3 months development then 6 months releasing. Adding more features means more bugs, so increases the release cycle even further.

The other thing that would help KiCad develop faster to throw out backward compatibility. With a larger team, you can afford to have multiple code modules handling different versions, KiCad does not have that luxury, there is only a single module which handles the latest version and also tries to parse all legacy features. That is a real millstone to carry round. Every new version adds a little more legacy baggage, and slows progress down further.

So my prediction for v6 is that it will be however long it took to do v5 plus a bit more. Therefore no earlier than December 2020. You read it here first!

5 Likes

Not so sure how you think my understanding in any way reflects upon the now current Cern published claims.

The new file format is pretty huge, it affects so much. I had thought there was a reasonably well drafted spec, which I partly implemented in Python to get a feel for it. Wayne now indicates it could change completely.

I suspect the actual development will follow the “reverse” method : code will be implemented to support a feature, then tested, then the file format description will (may!) be updated to reflect what was added to the file format. That is typically how KiCad has worked so far.

It’s worth remembering the new pcbnew format was in v4, v5 was “only” the change to OpenGL toolset.

So, are ALL OF THE ABOVE POSTERS, suggesting to NOT contribute to the Cern Effort to release V6 in 600 hours of paid Expert Development Time?

Your comment about 6.0.0-rc1 seems completely irrelevant to the Cern stuff, I don’t why you added it. It just gives the initial impression “I don’t really know what I am talking about”.

Anyway, I don’t know why you think that I think your understanding has any relation to what Cern claimed. You don’t work for Cern do you??

WHY do I keep getting sucked in to these pointless threads??? :smiley:

Now you are just TROLLING again… please STOP DOING THAT.

1 Like

I’m about to cancel my card payment to Cern based on these replies; that is not trolling.

Sent notice to my bank to reject the Cern payment based upon the replies here tonight.

Where did anyone say anything remotely like you should not contribute to Cern???

Your conclusion is just so perverse, illogical and irrational it can only be construed as trolling. Although I have to say that is consistent with your other posts.


I am not a huge fan of stackexchange, but we might do worse than adopt their “What is a good question?” formula.


In particular, the threads that go astray here are in the same category as “What kind of questions should I not ask here?”.

Since this thread has rapidly become one of those “useless” threads : invites speculation about the future, opinions exchanged with no meeting of minds, the title seems to hide a different agenda, I move to close.

4 Likes

Where in the video or the post do the guys from cern say that their estimate for v5.1 -> v6 is 600 hours?

All i can hear is that they would like to have money to pay 600 man hours “to get there faster” (This means without the money v6 will take longer then it does with it! Or it would mean that the v6 features will be reduced)

The reason for making the fundraiser now is that people will be happy shortly after an big update. It is also the time when a lot of people visit the website (meaning the yellow banner is seen by many people)

It is up to everyone themselves to decide if they deem kicad worthy of financial support. To be honest i find 600 man-hours a pathetically low amount of paid man-hours for such a large project.


Also worth noting: The current development is for the 5.1 release which aims at getting back python support for linux. This will of course delay the v6 development!

4 Likes

First of all, thank you for the donations! I am astonished by the contribution rate, I have not expected to find this quickly so many people willing to help develop KiCad!

We did our best to make it clear, but I will say it explicitly here: the donations are used to boost the development process, meaning shorten the time to reach v6. We plan to do so by outsourcing work whenever possible. It is not a kind of budget that would allow us to hire a team, but surely we can buy a few features. We would have never dared to promise that we will deliver v6 in 600 hours, both you and us realize how much effort it takes to release a new version. I swear I was getting even more impatient with v5 release than many users did.

Rene is right regarding 5.1 - we need to focus on wxGTK3 fixes now. This is one of unexpected obstacles that we need to deal with. It means that we want to release 5.1 soon, but it will not receive new features, just some minor improvements, mostly related to the user interface. The main goal is restore the user experience on modern Linux distributions.

9 Likes

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.