two reasons for using the "SNAPSHOT" rather than timestamp releases.
1.) with timestamped releases you will always need to run "mvn clean ..." during the build process because the assembly portion does not do complete transitive dependency analysis. You may end up seeing different versions of the same jar showing if you do not 2.) Using SNAPSHOT limits the number of release jars showing in the snapshot repository s that space used for these releases is fairly static. Keeping all releases around will create a larger snapshot repo. Some comments about the release process... a.) We should be doing more integration snapshot build releases of modules and trunk projects. b.) These should be on a shorter cycle than the scheduled release process. c.) Versions should change whenever a major customization is completed (AIP, Rest, etc). d.) We need Bamboo, it would alleviate a lack of automation for scheduling new snapshot and fixed release builds to only occur in concert with changes to the svn repository. I'm not against using timestamped snapshot releases, I just want to clarify the caveats. Finally, a slight tangent... I'd recommend since we are on the topic of maven... reviewing the poms also lead to an experiment to do async releases on the existing dspace svn trunk. a copy of the whole trunk, placed into the sandbox with version changes to be unique for each pom module under dspace/trunk and an attempt to show how/where async releases would end up in branches/tags. Finally, some adjustments to the maven build and assembly protocol to show how assembly happens once you have async releases and no longer distribute the source for the individual modules in the release installation zip. Mark On Wed, Aug 25, 2010 at 1:30 PM, Sands Alden Fish <sa...@mit.edu> wrote: > I have outlined some adjustments to the way DSpace is released concerning > POM configuration and which Maven artifacts are used by default when > building. I would appreciate it if anyone had time to review the proposal > for possible inclusion in the 1.7 release. It is located in the Development > Proposals section here: > https://wiki.duraspace.org/display/DSPACE/Proposals > > -- > sands fish > Software Engineer > MIT Libraries > Technology Research & Development > sa...@mit.edu > E25-131 > > > > > ------------------------------------------------------------------------------ > Sell apps to millions through the Intel(R) Atom(Tm) Developer Program > Be part of this innovative community and reach millions of netbook users > worldwide. Take advantage of special opportunities to increase revenue and > speed time-to-market. Join now, and jumpstart your future. > http://p.sf.net/sfu/intel-atom-d2d > _______________________________________________ > Dspace-devel mailing list > Dspace-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dspace-devel > > -- Mark R. Diggory Head of U.S. Operations - @mire http://www.atmire.com - Institutional Repository Solutions http://www.togather.eu - Before getting together, get t...@ther ------------------------------------------------------------------------------ Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d _______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
