On Fri, Aug 1, 2008 at 8:07 AM, [EMAIL PROTECTED] <
[EMAIL PROTECTED]> wrote:

> [EMAIL PROTECTED] schrieb:
>
>  Leonardo Uribe schrieb:
>>
>>>
>>>
>>> On Fri, Aug 1, 2008 at 7:33 AM, [EMAIL PROTECTED] <mailto:
>>> [EMAIL PROTECTED]> <[EMAIL PROTECTED] <mailto:
>>> [EMAIL PROTECTED]>> wrote:
>>>
>>>    Matthias Wessendorf schrieb:
>>>
>>>        On Fri, Aug 1, 2008 at 2:20 PM, Leonardo Uribe
>>>        <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
>>>                    Hi
>>>
>>>            As planned to release tomahawk, It could be good
>>>            (optional) to release
>>>            myfaces core 1.1.6. <http://1.1.6.>
>>>
>>>            Is there any task left to do this? If no I'll start the
>>>            release procedure.
>>>
>>>        sounds good to me
>>>            Sounds good to me too.
>>>
>>>    One thing I have meant to do is to check that all the info from
>>>    the (long obsolete) .xml files that sit next to the component
>>>    .java files has been migrated to an appropriate place, then remove
>>>    them. But that's not critical for a release.
>>>
>>>    I would suggest giving the release candidate for this a reasonable
>>>    time (>1 week) for the user community to test. There have been
>>>    some radical changes since the last release, and our unit tests
>>>    are not great so getting real-world testing for this would be very
>>>    useful.
>>>
>>>    But I would also suggest stating in the RC announcement that only
>>>    *regressions* from the 1.1.5 release will be looked at during the
>>>    rc cycle. We need to get the release cycles going again, even with
>>>    known issues - as long as they are not regressions.
>>>
>>>
>>> Ok, sounds good taking into account the latest changes, but I have never
>>> seen how a release candidate procedure works. I suppose it is the same as
>>> normal release but there is no vote, just an announcement about it and where
>>> to find the artifacts, and those artifacts are not published on main maven
>>> repo, right?
>>>
>> I think that passing around something that has the final version number in
>> it is too dangerous. So instead how about creating a tag dir, and updating
>> the version within that dir to "1.1.7-rc1", then just doing a build and
>> putting the artifacts up on people.apache.org?
>>
>> Then if testing goes ok, we can either generate the final release from the
>> rc tag dir, or just do a normal release again from trunk (presuming not too
>> much has changed since the rc was tagged).
>>
>> Ideally we would also push the 1.1.7-rc1 artifacts to the apache snapshot
>> repo, so that maven users can test this rc really easily. I'm not sure how
>> to do that, but it shouldn't be difficult; we can get the manually
>> downloadable artifacts there first, and figure out how to push to the
>> snapshot repo later...
>>
>
> (sorry, please read 1.1.6 instead of 1.1.7 above; got confused between core
> and tomahawk versions :-)
>
> Hmm..actually, what if its version is named 1.1.6-rc1-SNAPSHOT? That's more
> appropriate for pushing to the snapshot repo (and "mvn deploy will do so
> automatically). Does that version# come before or after 1.1.6-SNAPSHOT?
> Probably doesn't matter, as people will be pointing directly at one or the
> other.
>
> We could presumably do a tomahawk release candidate in the same way, and
> send it out for testing at the same time (ie tomahawk-1.1.7-rc1 can be sent
> out after core-1.1.6-rc1 but before core-1.1.6 has been released).
>

Good idea to put on snapshots repo as 1.16-rc1-SNAPSHOT (makes easier to
users test the artifacts), I'll try it and see what happens.


>
> Cheers,
> Simon
>
>

Reply via email to