mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julien Vermillard <jvermill...@gmail.com>
Subject Re: [VOTE] Release SSHd 0.7.0
Date Sat, 09 Jun 2012 05:45:47 GMT
On Fri, Jun 8, 2012 at 6:43 PM, sebb <sebbaz@gmail.com> wrote:
> On 8 June 2012 17:23, Guillaume Nodet <gnodet@gmail.com> wrote:
>> On Fri, Jun 8, 2012 at 6:09 PM, sebb <sebbaz@gmail.com> wrote:
>>> On 8 June 2012 17:00, Guillaume Nodet <gnodet@gmail.com> wrote:
>>>> On Fri, Jun 8, 2012 at 5:48 PM, sebb <sebbaz@gmail.com> wrote:
>>>>> On 8 June 2012 10:37, Guillaume Nodet <gnodet@gmail.com> wrote:
>>>>>> On Fri, Jun 8, 2012 at 11:25 AM, sebb <sebbaz@gmail.com> wrote:
>>>>>>> On 7 June 2012 16:10, Guillaume Nodet <gnodet@gmail.com>
>>>>>>>> I've uploaded a release at
>>>>>>>>   https://repository.apache.org/content/repositories/orgapachemina-201/
>>>>>>>> The release notes are available at
>>>>>>>>   https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310849&version=12317953
>>>>>>>> The vote will be opened for at least 72 hours.  Please review
and vote.
>>>>>>> Where is the SVN tag?
>>>>>> http://svn.apache.org/repos/asf/mina/sshd/tags/sshd-0.7.0/
>>>>> Ideally that should have an RC suffix in case the RC fails and has to
be redone.
>>>>> Otherwise the tag is not immutable.
>>>> That's up to the project to decide.  Over the 6 releases I've done on
>>>> sshd, this had not happened.
>>> In that case, it's best to include the tag and revision in RC votes.
>>> Otherwise one cannot trace provenance easily.
>>>> When it did happened in mina was mostly pre-major releases.  SSHD is
>>>> still in < 1.0 and I don't think we need to cut RC for minor releases.
>>>> Immutable tags means no one should ever change those.  But that's only
>>>> true after the release has been voted.
>>>> At least, that's what I've seen on the number of releases I did or
>>>> voted on at the ASF over the 10 projects and last 7 years.
>>>> And in all cases, each PMC has its own rules, and it does not seem to
>>>> be the case here.
>>>> Also, when using maven, you can't just rename a version.  It just does
>>>> not work for several reasons, one of them being that the version is
>>>> actually inside the jars at several places.
>>> It's perfectly possible to use RCn suffices with Maven projects.
>>> Commons (and HttpComponents) do that all the time.
>> I didn't say it's not possible, but you can't just rename the jars,
> No need to rename the jar.
> The jar does not need to have the RC suffix, just the tag.

Well we release like that since year in MINA, I don't think  a tag RC
prefix  worth a veto.
You plan to remove your veto if the NOTICE file and the licence header
are fixed ?

>> you'll have to the release again when you want to get rid of the
>> So I don't really see the benefit since you have to two at least 2
>> releases each time.
>> Usually, when a release fail (such as this one, as I need to cancel it
>> to add the missing headers), I delete the tag, drop the staging repo,
>> and try again.
>>>>>>> KEYS file?
>>>>>> http://svn.apache.org/repos/asf/mina/KEYS
>>>>>>> -1
>>>>>>> The NOTICE file in the source archive references code that is
>>>>>>> actually included.
>>>>>> Those are notices on the main dependencies, especially those inside
>>>>>> the binary distribution.  This is slightly over protective, but
>>>>>> on the good side is better.
>>>>> It's not good to claim that a release contains code when it does not.
>>>>> The NOTICE file is for *required* notices only.
>>>>> The dependency entries are obviously not required if they are not present.
>>>>> The contents of NOTICE files are generally transitive, so it's vital
>>>>> that they are accurate.
>>>> Yeah, that's not ideal I agree, but I'm not even sure how easily we
>>>> can change that atm.
>>>> I mean both distributions are generated in the same maven project and
>>>> they do use the same input afaik.

View raw message