Replying a bit late here, but...As long as the community agrees, the project can make the policy that there is no guarantee of any compatibility with major release 0.
Once there's a release 1, compatibility rules apply. Craig On Feb 20, 2009, at 10:31 AM, Shanti Subramanyam - PAE wrote:
This sounds good to me. But we still need to determine when we advance the minor number (I'm going to assume we will stick with a major number of 0 for now). I am not sure if the default understanding of "backward compatibility will be maintained for minor updates" will work for us (and in fact it doesn't work for other projects - hadoop 0.19.0 is incompatible with 0.18.x)Shanti On 02/19/09 21:17, Akara Sucharitakul wrote:I'm chiming in late here. There are pros and cons with both. The major.minor is good, but has to be advanced manually. You cannot automatically build it into the build/packaging process. The date can be automatically generated. In order to take advantage of both, I suggest having both mechanisms: 1. Use major minor as version number. I don't really care whether is major.minor or major.minor.dot, but prefer not to have the dot for less complexity. 2. Provide build date as part of the package. So instead of having something like snv_102 we'll have Olio 0.1 b021909 or Olio 0.1.1 b 021909. When we have a solid build, we'll just promote it to the official 0.1 and tag the repository with the build number. At least this is the way I do it in Faban and allows me to easily track issues when they are reported, even on non-final builds.-Akara Craig L Russell wrote:The way everyone describes the major.minor.update releases in this thread seem to be consistent.I have no vote, but if no one objects, go for it. Craig On Feb 18, 2009, at 3:45 PM, Damien Cooke wrote:Shanti,This mechanism for labeling releases is extremely simple and widely used. It provides people with an insight to the magnitude of the change. But what needs to be determined is what constitutes a x.x.X update and what constitutes an x.X.x update. In the past I have used X.x.x update for interface changes x.X.x update for functional enhancement and x.x.X for minor fixes.Regards Damien On 18/02/09 11:25 AM, Shanti Subramanyam wrote:Here are some guidelines for versioning : http://incubator.apache.org/guides/releasemanagement.html#best-practice-versioningI know Akara likes to use dates for release names and the guidelines above certainly don't preclude it. I checked the existing incubator projects and they're all using the / major.minor.point/ system of versioning. If we follow this convention, our first release will be 0.1.0. The advantage to this is that if we make only minor changes and/ or fix bugs we can simply update the point (to 0.1.1). This naming gives the user some idea of the level of changes that went in.Does anyone else have a suggestion or opinion on the above ? Shanti William Sobel wrote:A month sounds like it's doable, or should be! I think we already have a planned release structure in the repo. Now for the toughest question, how do we want to number the releases?Cheers, - Will Sobel-- <email_banner.gif> <http://www.sun.com/eco> *Damien Cooke* Open Scalable Solutions Performance Performance & Applications Engineering *Sun Microsystems * Level 2, East Wing 50 Grenfell Street, Adelaide SA 5000 Australia Phone x58315 (x7058315 US callers) Email [email protected]Craig L Russell Architect, Sun Java Enterprise System http://db.apache.org/jdo 408 276-5638 mailto:[email protected] P.S. A good JDO? O, Gasp!
Craig L Russell Architect, Sun Java Enterprise System http://db.apache.org/jdo 408 276-5638 mailto:[email protected] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
