geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jason.dil...@gmail.com
Subject Re: [vote] Release geronimo-jpa_3.0_spec-1.0
Date Fri, 22 Dec 2006 09:14:17 GMT
All of these impact the release, even if the code is not altered... Which is why it is important
to keep release artifacts in sync with release codebases.

And if you want to be sure to be able to reproduce a release you need to have the rev....
Otherwise you might pick up new changes made and not actually get the same result artifacts
when building.

--jason


  

-----Original Message-----
From: Matt Hogstrom <matt@hogstrom.org>
Date: Fri, 22 Dec 2006 00:09:37 
To:dev@geronimo.apache.org
Subject: Re: [vote] Release geronimo-jpa_3.0_spec-1.0

I think the SVN number would be needed as many times there are minor  
tweaks...a base SVN number would provide a reference point and people  
could see any commits (legal files, release notes, etc.) that don't  
impact the code.

On Dec 21, 2006, at 11:55 PM, Alan D. Cabrera wrote:

> I would imagine that a branch which is ready to be released would  
> be quiessed and so there would be no need for an svn rev # or am I  
> missing something?
>
>
> Regards,
> Alan
>
> On Dec 21, 2006, at 3:19 PM, jason.dillon@gmail.com wrote:
>
>> IMO using a svn rev # for a release is a good idea, that with a  
>> tag ensures that code for that exact release can always be found  
>> at a later time.
>>
>> --jason
>>
>>
>>
>>
>> -----Original Message-----
>> From: Matt Hogstrom <matt@hogstrom.org>
>> Date: Thu, 21 Dec 2006 18:10:46
>> To:dev@geronimo.apache.org
>> Subject: Re: [vote] Release geronimo-jpa_3.0_spec-1.0
>>
>>
>> On Dec 21, 2006, at 4:06 PM, Guillaume Nodet wrote:
>>
>>> I think voting on svn source for small projects / jars is good,
>>> because people can build them locally, check that everything
>>> is ok (for legal reasons), and vote.  This is much more difficult
>>> for Geronimo server, of course, and may not be applied.
>>>
>>> This works well, I think, if the release process is just
>>>   mvn release:prepare release:perform
>>> which should be the case for all projects ideally.
>>> The benefit is that the jars will be deployed to their final
>>> destination
>>> as part of the relase, without having to tweak / corrupting maven
>>> repository metadata by copying from a staging repo.
>>>
>>
>> For my part, I'd prefer to follow this approach going forward.  I
>> agree with Guillaume that it may not totally work for Geronimo unless
>> we choose an SVN number as the release point so people can track
>> changes to a branch.
>>
>> Having been through the release process a few times I think that
>> using Maven to generate the artifacts is so much simpler and
>> automagically updating the repo is far easier as well.
>>
>> I'd like to propose (in a separate thread) that we adopt this process
>> going forward for specs.  If the vote succeeds then I think David
>> could follow it for these specs as a test case.
>>
>> Matt Hogstrom
>> matt@hogstrom.org
>>
>>
>
>

Matt Hogstrom
matt@hogstrom.org


Mime
View raw message