Ron, Bengt, and all, I am definitely looking forward to the "best practice" for handling release and via maven release plug-in.
Meanwhile, 1. I agreed to what Ron's example about "messaging v.1.8.3". If we structure the code and build correctly, and if we can separate "messaging" as a stable module, then the "portal" software should depend on "messaging 1.8.3" in the maven dependency list. Isnt this how we use Maven? Thanks and looking forward to "best practice" from the Maven guys. B. On Thu, Sep 16, 2010 at 12:41 AM, Bengt Rodehav <be...@rodehav.com> wrote: > Ron, > > My explicit problems were more related to handling of CVS tags vs maven > versions - especially for release (or release candidate) builds. However, > you have a good point here. We always build the entire release from source > when we create a release. By releasing subsystems separately (instead of > releasing all inhouse artifacts every time), the release process will become > less complex. > > This will, of course, require better understanding of what changes are > required and what version of dependent artifacts you really depend on. This > is probably something that a good development process should provide anyhow. > We have a similar situation to the one you describe. Our lowest level > framework is very stable and hasn't changed for a very long time. Yet we > rebuild it every time and create a new release. Perhaps we should create a > separate release of those frameworks and have other artifacts depend on that > stable release instead of on a snapshot version? > > Deciding what artifacts (or group of artifacts) to release separately is a > subject that should be given a lot of thought. I'm very interested in "best > practices" in this area as well. > > /Bengt > > 2010/9/15 Ron Wheeler <rwhee...@artifact-software.com> > >> Does anyone have a "Best Practice" already written for this? >> >> From what I understand: >> a) since releases are immutable, you can only deploy a release once. >> b) you are allowed to deploy snapshots as often as you want >> c) a human being needs to decide when you are starting to build releases. >> d) you can use alpha, beta, release candidates RC1, RC2, RC3, etc. to >> identify releases prior to a cleanly numbered release. Someone once wrote a >> forum note about this, I think. >> e) different parts of an application can be at different stages in a >> release but this does create a need for careful management and some >> consideration in a continuous build environment. >> We got tired of (and ran out of time for) changing release numbers on >> modules that did not change as fast as the application. For example, our >> release 1.10 of the overall application depends on messaging utility 1.8.3 >> since the messaging utility has not changed since 1.8.3 was released. We >> have over 60 projects in our portal application and only 3 people in >> development so we can not change and rebuild and rerelease 55 projects just >> because 5 modules got upgraded going from 1.9 to 1.10. >> As we moved more functionality into services, we got more stability in the >> modules and it appeared that we were spending too much time redeploying >> modules with new versions and the same functionality. >> We decided that it was alright for release 1.9 of the ContractAdmin war to >> have a dependency on 1.8.3 of the messaging system jar. >> We do have some aggregation jars that help manage this by creating a single >> 1.10 OurLibraries jar that has the right dependencies of the utilities such >> as messaging. >> >> It does require a bit of planning and coordination where a decision to add >> a function to the messaging utility to accommodate a new function in a >> dependent module has to be addressed by the entire team and those modules >> that use the messaging utility need to have their dependencies changed and >> also need more testing than they might have got if they were not changing or >> their dependencies were not changing. >> >> Not sure how this relates to other environments and I do not think that >> this is a candidate for a "Best Practice" until others have used it and >> found that it solves a problem in a certain development environment. It is >> probably not suitable for large teams where the cost of coordination exceeds >> the cost of upgrading releases. For a small team, where rereleasing 55 >> modules can be avoided >> by a few extra question in 30 minute planning session and a 15 minute >> review prior to going into test and a short conference or e-mail when a >> module has to be changed that was not on the original list for the release, >> this appears to work. >> >> Ron >> >> >> On 15/09/2010 6:09 AM, Bengt Rodehav wrote: >> >>> Thanks for your input Baptiste, >>> >>> Yes, we have been debating the relase process a bit here. Keeping the >>> relase >>> process separate would e g mean that we know beforehand that we want to >>> build a release candidate. We could then start with the tagging and then >>> checkout on this tag for the build of the release candidate. >>> >>> Not quite sure what you mean by: >>> >>> (even if, imo, if you're depending on a snapshot revision, and try >>> >>> debugging a snapshot version that's not the dev version, you have a >>> problem >>> >>> in your dev process) >>> >>> >>> Our central, nightly builds do not use published snapshots but always >>> checks >>> out from CVS and then build from source. I agree that if a central build >>> (that could be a release candidate) was built using published snapshots, >>> we >>> would have a problem. >>> >>> /Bengt >>> >>> >>> 2010/9/15 Baptiste MATHUS<m...@batmat.net> >>> >>> Yes, this is a typical, almost specific CVS problem that's >>>> understandable. >>>> As the versioning is done at the file level, and not at the repo one, it >>>> can >>>> be necessary to tag to be able to identify the code corresponding to a >>>> snapshot (even if, imo, if you're depending on a snapshot revision, and >>>> try >>>> debugging a snapshot version that's not the dev version, you have a >>>> problem >>>> in your dev process). >>>> >>>> This problem doesn't exist with SVN. For example, we use the >>>> buildnumber-maven-plugin and add the svn repository revision number to >>>> the >>>> manifest for each build. So finding corresponding code for a jar is no >>>> problem at all for us, but we actually hardly need it. >>>> >>>> For the dev process, only in my opinion, I think automatically releasing >>>> every nights isn't a very good pratice. I rather think the release >>>> process >>>> should be actually 100% standalone, but *manually* initiated (giving the >>>> new >>>> version and so). >>>> >>>> Cheers >>>> >>>> 2010/9/15 Bengt Rodehav<be...@rodehav.com> >>>> >>>> We've had similar questions where I work. The question has been related >>>>> >>>> to >>>> >>>>> how and when to create tags in CVS (preferrably using the >>>>> maven-release-plugin). >>>>> >>>>> Some people advocate tagging every build so that it can be recreated in >>>>> case >>>>> it was fit for delivery. This is a problem when using CVS since huge >>>>> >>>> number >>>> >>>>> of tags are not handled very well. >>>>> >>>>> However, builds that could potentially become a released version must be >>>>> recreatable somehow which implies a tag in the version control system. >>>>> Whenever a "release candidate" is built, doesn't it have to be tagged - >>>>> >>>> and >>>> >>>>> therefore released? >>>>> >>>>> When we enter a system testing period close to the release of a new >>>>> version. >>>>> We normally build and deploy new versions automatically every day. At >>>>> >>>> some >>>> >>>>> point we decide that it's good enough to release. It is then imperative >>>>> that >>>>> the latest build (which we have used for testing) is the one we package >>>>> >>>> and >>>> >>>>> tag. >>>>> >>>>> What are the best practices around this? I'm very curious to know how >>>>> >>>> other >>>> >>>>> organisations handle this using maven. >>>>> >>>>> /Bengt >>>>> >>>>> >>>>> 2010/9/15 Baptiste MATHUS<m...@batmat.net> >>>>> >>>>> Well, for example, we don't release automatically. We launch manually >>>>>> >>>>> it >>>> >>>>> via a special release plugin through hudson, itself launching a maven >>>>>> release through the maven-release-plugin. >>>>>> >>>>>> This makes it easier to keep a clean release environment. Releasing >>>>>> >>>>> from >>>> >>>>> a >>>>> >>>>>> development machine would add risk since it (1) might be less close to >>>>>> >>>>> the >>>>> >>>>>> production system and (2) might contain things depending on the dev box >>>>>> that >>>>>> wasn't added to the SCM. >>>>>> >>>>>> Snapshot builds are totally sufficient for us to handle testing >>>>>> >>>>> purposes. >>>> >>>>> Cheers >>>>>> >>>>>> 2010/9/15 baz themail<bazthem...@gmail.com> >>>>>> >>>>>> Hi, >>>>>>> >>>>>>> I have been searching the maven website and articles but not sure if >>>>>>> >>>>>> i >>>> >>>>> get the best practice for managing snapshots and release. >>>>>>> Specifically, if continuous builds produce maven snapshot builds, >>>>>>> >>>>>> then >>>> >>>>> when will i produce maven release builds using maven release plug-in? >>>>>>> >>>>>>> Will I ever produce a maven release build via an automated build job >>>>>>> that runs daily for example? The problem with that is: Because maven >>>>>>> plugin is incrementing pom.xml, and the automated build job will >>>>>>> always detect changes even tho there is no changes in the produce >>>>>>> software code. Does it even make sense? Or, release build should be >>>>>>> run manually depending on the release schedule? >>>>>>> >>>>>>> Thank you. >>>>>>> >>>>>>> A. >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >>>>>>> For additional commands, e-mail: users-h...@maven.apache.org >>>>>>> >>>>>>> >>>>>>> >>>>>> -- >>>>>> Baptiste<Batmat> MATHUS - http://batmat.net >>>>>> Sauvez un arbre, >>>>>> Mangez un castor ! >>>>>> >>>>>> >>>> >>>> -- >>>> Baptiste<Batmat> MATHUS - http://batmat.net >>>> Sauvez un arbre, >>>> Mangez un castor ! >>>> >>>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
