On Wed, Jun 15, 2011 at 9:57 AM, sebb <seb...@gmail.com> wrote: > On 15 June 2011 15:34, Matt Benson <gudnabr...@gmail.com> wrote: >> On Wed, Jun 15, 2011 at 6:56 AM, Gilles Sadowski >> <gil...@harfang.homelinux.org> wrote: >>> On Wed, Jun 15, 2011 at 09:31:24AM +0100, sebb wrote: >>>> For components that use Nexus, it's trivial to use mvn deploy on a >>>> SNAPSHOT release. >>>> >>>> This can be useful for developers to check that a patch solves their >>>> problem. >>>> >>>> However, snapshots should not be advertised to the general user >>>> public, so should never be referenced from download pages, nor on the >>>> user list. >>>> >>>> But AFAIK it would be OK to mention the snapshot on the JIRA issue. >>>> >>>> There are also some projects that use the CI servers to upload >>>> snapshots. Not sure how that is done. >>> >>> It would be nice to have a "latest" snapshot together with all snapshots >>> that are supposed to solve a given issue. "latest" would be overwritten by >>> the last issue snapshot. >>> E.g. assuming that issue (MATH-799) is resolved, the following snapshots >>> would be available: >>> >>> math-commons.MATH-774.jar >>> math-commons.latest.jar -> math-commons.MATH-774.jar >>> >>> Then, later, when issue MATH-768 is resolved: >>> >>> math-commons.MATH-774.jar >>> math-commons.MATH-768.jar >>> math-commons.latest.jar -> math-commons.MATH-768.jar >>> >> >> This snapshot-per-resolved-issue scheme certainly isn't something I'd >> care to implement by hand. I don't really think that degree of detail >> is necessary. > > +1, latest should be sufficient for checking if the issues are resolved. > >> It would be nice to publish our CI builds to the >> snapshots repo. These are typically dated in the repo. E.g. Jenkins >> will have svn info available per-build, so the only piece potentially >> missing from this mixture would be the correlation between a given >> snapshot and the Jenkins build. > > JMeter solves this by including the svn info as part of the version > id, which is logged/displayed on startup. > It also uses the revision as part of the snapshot build name. > > This is done with Ant, but it should be easy enough to adapt the code > for Maven builds. > > I don't think it will be possible to rename the snapshot artifacts, as > they are auto-generated by Maven, but updating the code should be easy > enough, and it might even be possible to add the SVN info to the > manifest which is present in all jars. > >> Not sure how the other available CI >> options stack up in this regard. Since AFAIK our CI builds currently >> are done in Continuum, I would be shocked to find that publishing a >> snapshot isn't part of its repertoire. > > No idea whether Continuum supports snapshot publication - try asking > on the builds@a.o list. > > However, this will all take some effort to achieve. > > In the short term, the occasional manual mvn deploy + update of JIRA > with the reference should work for many use cases.
I would amend to say a simple "I have published a SNAPSHOT containing this fix" should be enough for JIRA. Usually once fixed, things stay fixed, time being something we only know how to move through in a forward direction and all. Matt > >> Matt >> >>> [Such a history might be useful to help users spot which change might have >>> resulted in breaking something.] >>> >>> >>> Best regards, >>> Gilles >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
