On Fri, Jun 8, 2012 at 6:09 PM, sebb <[email protected]> wrote: > On 8 June 2012 17:00, Guillaume Nodet <[email protected]> wrote: >> On Fri, Jun 8, 2012 at 5:48 PM, sebb <[email protected]> wrote: >>> On 8 June 2012 10:37, Guillaume Nodet <[email protected]> wrote: >>>> On Fri, Jun 8, 2012 at 11:25 AM, sebb <[email protected]> wrote: >>>>> On 7 June 2012 16:10, Guillaume Nodet <[email protected]> wrote: >>>>>> 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, you'll have to the release again when you want to get rid of the rc. 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 not >>>>> actually included. >>>> >>>> Those are notices on the main dependencies, especially those inside >>>> the binary distribution. This is slightly over protective, but erring >>>> 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. >> >>> >>>>> >>>>>> -- >>>>>> ------------------------ >>>>>> Guillaume Nodet >>>>>> ------------------------ >>>>>> Blog: http://gnodet.blogspot.com/ >>>>>> ------------------------ >>>>>> FuseSource, Integration everywhere >>>>>> http://fusesource.com >>>> >>>> >>>> >>>> -- >>>> ------------------------ >>>> Guillaume Nodet >>>> ------------------------ >>>> Blog: http://gnodet.blogspot.com/ >>>> ------------------------ >>>> FuseSource, Integration everywhere >>>> http://fusesource.com >> >> >> >> -- >> ------------------------ >> Guillaume Nodet >> ------------------------ >> Blog: http://gnodet.blogspot.com/ >> ------------------------ >> FuseSource, Integration everywhere >> http://fusesource.com -- ------------------------ Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ FuseSource, Integration everywhere http://fusesource.com
