commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <>
Subject Re: [Math] download development snapshot
Date Wed, 15 Jun 2011 15:02:36 GMT
On Wed, Jun 15, 2011 at 9:57 AM, sebb <> wrote:
> On 15 June 2011 15:34, Matt Benson <> wrote:
>> On Wed, Jun 15, 2011 at 6:56 AM, Gilles Sadowski
>> <> 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
>>> [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:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message