On 6/15/11 8:02 AM, Matt Benson wrote: > 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.
I don't like the idea of having JIRA refer to snapshots or doing anything that dignifies specific snaps. Adding a comment referring to a revision number where the issue is patched is enough, IMO. I would be OK publishing links to nightlies as we used to do (and I seem to recall it is still possible to grab them from Continuum); but I think we should stay away from publishing anything that looks like a milestone snap. I also think the best JIRA flow is RESOLVE when fixed in svn and CLOSE when released. I agree with Luc though that in general people who want to use trunk should build it themselves. I would personally never rely on an unreleased OSS snap or provide it to anyone else [1]. If I did use the code, I would be basically signing up to use and support the source myself and being set up to build it is essential for that. So FWIW, my advice to anyone using any of our stuff from trunk is build it from source. If you need help getting the build to work, just ask. And of course, when you notice bugs or see opportunities to improve, patches welcome! Phil [1] Some people will point out that unfortunately it is very hard to never rely on unreleased snaps via transitive dependencies. This is sadly true. > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
