| Thread Previous • Date Previous • Date Next • Thread Next |
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@470notice that @470, this is the subversion version number, and there can be a small handful of them in the kicad-2007-Nov subtree.
orsvn 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
| Thread Previous • Date Previous • Date Next • Thread Next |
