Hi Man-Chi, About the Maven conventions, you can check out the first paragraph of http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution
HTH, - Yann On 4/5/06, Eric Redmond <[EMAIL PROTECTED]> wrote: > > 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.1versus > 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] > > > > > >
