kicad-developers team mailing list archive

[Dick Hollenbeck <dick@...>]

David Bourgeois wrote:
> On Thu, 22 Nov 2007 18:19:06 +0100, Igor Plyatov <plyatov@...> wrote:
>
>
> > Hello Dick!
> >
> > > 1) The November release candidate has been copied into
> > > *https://kicad.svn.sourceforge.net/svnroot/kicad/tags/kicad-2007-Nov*
> > >
> > > Notice that the day of month has been dropped and we are using 'Nov'
> > > instead of 11.
> > Who is this "we"? ;-)
> > Such enumeration of versions is undesirable for example in my Gentoo 
> > Linux.
> > It is impossible to correctly compare such versions at package upgrade.
> > The examples of good version numbering:
> > 1.4
> > 1.4.2
> > 1.4-r2 (2 - is a release of package)
> > 200711
> > 20071122
> > 200711-r468 (468 - is a SVN revision)
> > 20071122-r468 (468 - is a SVN revision)
> > r468
> >
> > Can we come to the consensus with KiCad versioning?
> >
> > My propositions of numbering:
> > 200711
> > 20071122
> > or maybe 2.0
> >
> > P.S. This is not a criticism, but a requirement for some compatibility.
> Hi Dick and Igor,
>
> (Just my 2 cents.) I thought that tags were not meant to be changed at all 
> as they represent a frozen release. In my understanding, I was expecting a 
> tag (for the current release) and a branch for future bug fixes. The 
> branch can be named kicad-2007-Nov or whatever but the tag should better 
> be a number (friendlyness with most package managers). I'd personnaly vote 
> for '20071122' as that's how past releases were done already.
> Cheers,
> David Bourgeois
The subversion architecture is pretty flexible. How we lay out the 
tree is by convention, and convention is what we make it. The subtree I 
created is meant to be "stable", and possibly frozen. In practice, 
software that is frozen is software that keeps its bugs.
The difference between frozen and stable is a function of how many bugs 
people want to fix. If you want it frozen, then don't change anything 
in that subtree. My expectations are that this new subtree would get 2 
to 10 bug fixes max before that subtree dies out and people switch back 
to trunk a month or two from now. I don't really understand all the 
commotion.
As to the remark about "branch" vs "tags", I saw no purpose in having 
both of them for a release or a release candidate. A branch tree would 
be useful for temporary "out of trunk" work, which eventually gets 
merged and then deleted. This Nov-2007 release is no such thing. With 
too many subtrees, it would mean that changes may need to be merged or 
copied across to each one, causing more work. There are not enough 
man-hours donated here as it is. 

As for version numbering, IMO we have that in the svn mechanism. If you 
want to describe a particular version, you can always do so as follows:
https://kicad.svn.sourceforge.net/svnroot/kicad/tags/kicad-2007-Nov@470


notice that @470, this is the subversion version number, and there can 
be a small handful of them in the kicad-2007-Nov subtree.
or

svn switch 
https://kicad.svn.sourceforge.net/svnroot/kicad/tags/kicad-2007-Nov@470

Within the kicad-2007-Nov subtree, there will not be a lot of separate 
versions, at most two months worth, maybe 2 to 10 bug fixes. If you 
like a particular version other than the most recent found within the 
subtree (which presumably would have the largest number of bugs fixed), 
then remember the subversion version number for it and tell your friends 
about that so they can check it out.
Nothing I have heard in the most recent postings persuade me to believe 
that we are going down anything but the best path. But I am still 
listening if you care to elaborate your point of view and describe a 
particular example scenario that we cannot address easily in the next 
two months or at any other time.
Also, remember that the "release candidate" becomes a "release" when 
binaries are made and put out for folks who don't build it themselves. 
The exact date of that is not known until it happens, when bugs slow 
down. And here's the important driver: in the mean time work needs 
to happen on the NEXT release, namely the improved zone support. So the 
November release had to be put some place "stable". 

The binaries can have any name or version number that folks want to give 
them. That is what most users get. Somebody can document on this list 
or in the readme file, an association between the binary version number 
used, and the subversion version number within the kicad-2007-Nov tree, 
at the time the binaries are released, and then anybody can rebuild that 
binary exactly any time in the future.

Again, I think what we have is good, it works for me anyway.


Dick Hollenbeck
SoftPLC Corporation
http://softplc.com