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. >>>> >>>> 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
