commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@gmail.com>
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 <sebbaz@gmail.com> wrote:
> On 15 June 2011 15:34, Matt Benson <gudnabrsam@gmail.com> wrote:
>> On Wed, Jun 15, 2011 at 6:56 AM, Gilles Sadowski
>> <gilles@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-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message