geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevan Miller <kevan.mil...@gmail.com>
Subject Re: [vote] Release geronimo-jpa_3.0_spec-1.0
Date Sat, 23 Dec 2006 17:26:44 GMT
I like the precision of an branch+RC. It leaves no doubt on what is  
being voted on.

IMO, we should be voting on binaries AND source code simultaneously.  
I think it's helpful for the release manager to provide the binary.

Given some of the recent issues of snapshot dependencies, etc. We  
also should make an effort of validating that released code can be  
built from a clean repo.

--kevan

On Dec 22, 2006, at 10:12 AM, Matt Hogstrom wrote:

> I agree...I think you have an SVN base number that you start  
> from...you do the work in branches, make small tweaks, etc.  
> (remember, we're trusting the the release manager and our friends :)
>
> When you release Maven makes the move of the released branch to  
> tags.  So the base SVN number is merely a starting point.
>
> On Dec 22, 2006, at 4:14 AM, jason.dillon@gmail.com wrote:
>
>> 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
>>
>>
>
> Matt Hogstrom
> matt@hogstrom.org
>
>


Mime
View raw message