kicad-developers team mailing list archive
Mailing list archive
Re: Subversion Changes
Dick Hollenbeck <dick@...>
Thu, 22 Nov 2007 22:49:37 -0600
Thunderbird 18.104.22.168 (X11/20071022)
David Bourgeois wrote:
On Thu, 22 Nov 2007 18:19:06 +0100, Igor Plyatov <plyatov@...> wrote:
1) The November release candidate has been copied into
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
It is impossible to correctly compare such versions at package upgrade.
The examples of good version numbering:
1.4-r2 (2 - is a release of package)
200711-r468 (468 - is a SVN revision)
20071122-r468 (468 - is a SVN revision)
Can we come to the consensus with KiCad versioning?
My propositions of numbering:
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.
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
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:
notice that @470, this is the subversion version number, and there can
be a small handful of them in the kicad-2007-Nov subtree.
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.