Well, sorry to dissapoint, but I'm not an expert... I am, however, full of opinions!
This is how I tend to number, and it works well for me: Skip bugfix numbering unless you are working on a major project. Seriously. It gets very burdonsome to handle multiple minor edits on smaller projects, since they either 1) change a lot... meaning that all of their dependencies are expected to change? Naw, just use SNAPSHOTs or timestamps. 2) rarely change... meaning, why would you need to keep track of version 1.0.1 versus 1.0.2? Now, that said, bugfix numbering is good for larger projects, like linux, jboss, or maven. The difference between 2.0.0 and 2.0.3 is fairly substantial. So, what's the difference between a small and large project? Well, thats up to you. Just don't get overzealous. Remember: you can always add decimals later, but its hard to take them away (try and explain to your users and developers why you moved from 1.1.0.1a to the number 2: "what version is this, really"?). Parent and aggregator projects (pom packages) can live quite well with a single number. 1, 2, 3... no need to complicate matters, they don't change enough to need minor numbers, and when they do, its a pretty major change for their children. Addendum to the previous statment: if the artifact is the top aggregator of a large project. Since this version will tend to be the project's actual version, use the actual project's numbering scheme. I also like to use the *-alpha-1, *-beta-3, *-RC-1 style of naming. It works, its descriptive, and it lets users know if they're using a beta project right off the bat. I'd love the chat more, but the new episode of "House" is on! Hope this helps; Eric On 4/4/06, Man-Chi Leung <[EMAIL PROTECTED]> wrote: > > hi, > > sorry that it is not a direct question on Maven usage, but I really > hope to improve my Release management process with Maven. > > I would like to understand more regarding version numbering > convention, perhaps, the most commonly practice in Java community. > > 1) for subversion source tree. it is using Release.Minor.Bugfix- > ReleaseCandidate scheme > e.g. from 1.0.x -> 1.1.x ->1.2.x -> 1.3.x > 1.3.x-rc1 -> 1.3.x-rc2 -> 1.3.x-rc3 > > 2) in linux kernel, 1.x , odd-numbered releases (2.5, 2.7, etc.) are > unstable development versions, while even-numbered releases (2.6, > 2.8, etc.) are stable consumer releases. > > 3) Eclipse community is using a term "Milestone". it is from 2.x M1 - > > 2.xM2 ... -> 2.xM6 -> 3.x , etc > > 4) Apple is practicing number-letter-number scheme, also having > development version & marketing version > e.g first build of Panther (10.3) was 7A1. The first public release > was 7B85; the last, 10.3.9, was 7W98. But the next build of OS X was > 10.4, 8A1 > > 5) in general, there is also 1.x apha , 1.x beta , 1.x final release. > etc > > 6) in Maven and relating maven plugin, there is a SNAPSHOT scheme. > i would like to find out more about the differences and good > practice. any expert can help? > > thanks so much for help and advice! > > Regards, > manchi > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
