Does it make sense to have development snapshots for the v5.1 branch going forward?


#1

Now we have the problem with confusion about Nightly versions again.
Do we have the server space now to allow both V6 development branch Nightlies aka Master and the 5.1.x tree? Right now I am more interested in what will be future 5.1 point releases.
Some sort of clear directory identification is needed


Post-v5 new features and development news
#2

The confusion for new KiCad users to understand what version they are using is very likely to keep getting worse.

How about 5.1.0-071 instead of the above mess?

The “071” is today’s Julian Date with a leading zero so that it is always three (3) digits in length.

And, perhaps add a second string in the middle, such as…

5.1.0-id-701
5.1.0-rc-701
5.1.0-tg-701

The string
“id” - Initial Development; as in starting a new branch
“rc” - Release Candidate; as in just about to tag a branch
“tg” - TagGed release; waiting for everything to catch up before announcing Official Release of version.

This would be very easy way for forum members to answer questions that have different answers based upon the version of KiCad that is being used at the time.


#3

Only bugfixes as always with minor releases. Meaning no need for nightlies here.


The above “mess” is the git commit hash. (The reason the hash is used instead of the day is because there is more than one commit per day. This is the only way to uniquely identify git commits with a single string of numbers.)

I also seem to remember that there was the string “dev” somewhere in the name in the past. This was to make it even clearer that the version is a development snapshot not a release. Has this gone now?


Using nightlies requires users to know what they are doing to be honest. They are meant for testing the software and giving feedback. They are not for productive work. (As explained in my FAQ article)

Yes i know the nightlies have been quite tame for a while. But that was an exceptional period. Now we will again get the problem of no more forward compatibility.


#4

I would not be expecting a new 5.1 fork build every day, but GitHub activity of cherry picked
bug fixes is going to be quite significant when 5.1.0 actually gets formally released.
Past experience tells me that we will probably be on 5.1.5 by the time a true 6.0.0 rc1 appears


#5

They can selectively decide to publish nightly builds or at least rc’s for point releases if needed. All changes which go to 5.1.x should be in master development branch and nightly builds already before they are in the point releases (unless something has been changed so radically that a fix to a point release can’t apply to master development).


#6

Once the schematic changes for 6 start, v5 bug fixes are likely to NOT be in master


#7

I am quite sure the v4 bugfixes where cherry-picked (*) from master and not specially developed just for v4. (After all a bugfix for v4 is likely to be needed for v5 as well. I would guess something similar will be true for v5 fixes and v6.) But you might want to ask over on the mailing list for details about something that deep into the development workflow specifics.

*) cherry pick is a powerful git command that can take a single commit (or a range of commits) from one branch and apply it on another as a new commit.