I would give you approach a big thumbs up with one exception... use [1,2-!) not [1.0.0,) otherwise you can't carry out concurrent development and patching... you need to be able to isolate the major version with ranges...
oh and never start your version as 1.0 always start at 1.1 if you expect ranges to work properly... On Wed, 08 Oct 2008 14:22:34 Simone Gianni wrote: > Hi Stefan, > I don't know if I got the problem right and if this could be a solution, > but I do as follows (obviously, we are talking about "maven branching", > not SVN or CVS branching, which is another story) : > - setup a developers only maven repository > - setup a production only maven repository > - use range versions instead of fixed ones > .. This means that instead of having a dependency on artifact > com.yourcompany:artifact:1.0.0 you have a dependency on > com.yourcompany:artifact any version > 1.0.0 > - when a subproject is buggy, a team (or single developer, or whatever) > will start working on it > - they will build it on their own computers (in their local repository), > so no problem with them testing their own work > - they will occasionally deploy it TO THE DEV ONLY repository > .. deploying it there, will let the other teams use the new artifact and > test that their own work is correct related to the new > bugfixes/refactorings and so on > .. obviously, when they deploy, they should increment the minor > version/revision, but only on that project specific pom (for example > 1.0.0-r1 1.0.0-r2 or 1.0.1 1.0.2 etc...) > - when the bugs have been fixed, the deploy can be made on the > production only maven repository > - from there, a complete build and test of the application can be done, > and final release (war, jars or whatever) created to send to customers > > This way, every project can have its own "lifecycle", its own releases, > and probably its own SVN branches and so on. While using fixed version > dependencies is a good practice when linking to something outside your > control (artifacts on the main repo), for internal dependencies > (artifacts produced inside your company/team) it is a maintenance > nightmare and most of the time useless, cause you know when a new > version will break compatibility and can adjust versioning only when > that happens. > > Using SNAPSHOTS can save a bit of time making the "change the version > when sending to other developers" step not necessary, but I think that > it should be avoided when there is a high number of developers : that > step can potentially break the build and stop other developers' work if > the new package breaks compatibility when it should not or introduces > more bugs than the previous one (which obviously happens :) ), and > having also these "internal" releases versioned is IMHO more time-saving > than using automagic snapshot updates. > > Hope this helps, > Simone -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
