We've agreed to this. 1.5 is a special exception. We'll only make special exceptions in the future if we completely revamp our package structure and move to apache again....wait...we can't do it again... . so 1.5 is a special exception.
However our existing versioning scheme is this: 1.0.0 = major release 1.0.1 = bugfix release...1.0.2...etc 1.1.x = a development build for 2.0 where 1.22 is still a development build for 2.0 1.1.1 = a development build for 2.0 with a little bug (lets never do that again) fix so 1.5 is a total exception based on exceptional circumstances..... (the rebirth of POI on Jakarta) 2.0.0 will be the next major release and then... 2.0.1 will be the bugfix on that 2.1.0 will be the first 3.0 dev build I'm open to revising this but we need a versioning scheme that supports dev builds and bug fixes. The current scheme that we're violating right now grew out of the funkiness of sourceforge's release system. So propose something that supports that and I'll +1 it and +1 to you adapting centipede and documenting the process so that Glen the release master can follow it ;-) -- and then we can make it a resolution ;-) On Sun, 2002-04-21 at 14:14, Nicola Ken Barozzi wrote: > From: "Andrew C. Oliver" <[EMAIL PROTECTED]> > > > Hi All and especially those of you who ride Kangaroos to work everyday, > > > > It occurs to me that some of the things I'm about to do are heavily > > HSSF-2.0 oriented and yet I'm not yet sure we'll be ready for 1.5. > > Everytime I think we're RealClose(tm) a Gigantic moth sized anywhere > > from little to gigantic flies into the works and gums them all up. So > > "to branch or not to branch" that is the question! > > > > Secondly, after we release 1.5, we'll undoubtedly have a 1.5.1 or > > something of the such to capture bug fixes/etc. So the question before > > you: > > > > do we create a branch for 1.5 and continue all bug fixes there while > > continuing further development on the head. > > > > I vote +1 - if Glen doesn't have the necessary CVS-foo I'll fake it. ;-) > > > > Later votes or discussions can determine the status of particular pieces > > of code. I say all formula related stuff goes in the head and not in > > 1.5. > > AFAIK branching for a release is common practice, so that bugfixes can go in > that branch. > > So I'm +1. > > I'd add that I would like to see this become a resolution, and part of the > development rules. > > Version is: X.x.f > > X = major version. usually at apache it means complete refactoring > x = minor version. builds new functionality in the same X architecture > f = only bugfixes. > > X and x are tho only *real* releases with new functionality. > Each time X and x get released, a new branch is created for bugfixes. > f versions are rolled out as needed by the severity of the bugs fixed, but > will not contain new functionality. > > So, how does this look? > > -- > Nicola Ken Barozzi [EMAIL PROTECTED] > - verba volant, scripta manent - > (discussions get forgotten, just code remains) > --------------------------------------------------------------------- > -- http://www.superlinksoftware.com http://jakarta.apache.org/poi - port of Excel/Word/OLE 2 Compound Document format to java http://developer.java.sun.com/developer/bugParade/bugs/4487555.html - fix java generics! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh
