A long term support version of River 2.2.x should be sufficient to keep those who desire minimal change satisfied, without them feeling threatened by a more progressive pace of development. Git would make managing the separate branches easier.
Bugs that were reported and fixed in 2.2.x were often already fixed in the trunk branch. Also there are tests in the 2.2.x branch that fail, because they're unmaintained, these tests haven't passed on recent jvm's. Determining bug fixes that go into the lts support branch is somewhat difficult, clearly race condition fixes wouldn't be included, nor would security fixes, I'd suggest only the occassional major bug reported by users of the lts version. The 2.2.x branch code is written to the old java memory model, prior to JSR133 released with Java 1.5. If we based the River 2.2.x lts support on the availability of support for suitable jvm's and Oracle's end of public updates, the lts River version 2.2.x branch would probably end late 2017 or early 2018. The US is predicted to have 70% IPv6 deployment by that time. Support for loading the policy provider into the extension ClassLoader will be removed in Java 9, this will reintroduce a policy deadlock bug for 2.2.x that were fixed by loading policy providers into the extension ClassLoader. These bugs won't affect River 3.0. Back porting the policy provider from River 3.0 is not an option, as this is almost non blocking (very good for avoiding deadlock) and would cause many latent race condition bugs to emerge. If River 3.0.0 is released soon, that allows two years for migration, remembering that River 3.0.0 is largely a JMM compliance bug fix release, with a com.sun.jini to org.apache.river namespace change. After River 3, I'd like to see focus on IPv6, security (fixes, updates and simplification), IoT and a protocol based lookup service that supports other languages. Regards, Peter. Sent from my Samsung device. Include original message ---- Original message ---- From: Bryan Thompson <br...@blazegraph.com> Sent: 06/07/2016 11:22:49 pm To: dev@river.apache.org <dev@river.apache.org> Subject: Re: Attic? Was: Re: Lotj - languages other than java I look at git in terms of the ease of use for branch/merge patterns and the support of pull requests for code review and historical change tracking. It is really far superior in its flexibility. Even just the diff facility if a big step forward. I do agree that projects benefit significantly from governance. If it degenerates to everyone creating their own fork then nothing good would come of that. I am not suggesting git because it makes forking easier. But because it makes team development easier. Bryan On Wednesday, July 6, 2016, Simon IJskes - QCG <si...@qcg.nl> wrote: > On 05-07-16 14:51, Bryan Thompson wrote: > >> GitHub (at least) provides excellent tracking. It is a matter of how you >> define policy for PRs. We do not accept PRs unless the author is a >> contributor with appropriate CLAs for the project. So it works out very >> nicely for us. Every single commit and its authorship remains visible and >> that metadata can be easily accessed. >> > > Is changing the version control system really going to change the problems > we have? > > The same goes for maven or not, gradle or ant, etc. > > One direction wants a stable release with bugfixes, and strict maintaining > of the original api, the other side wants to change things. > > No resolution in sight. I really like the Apache governance, and it gives > everybody the freedom to fork it under its own. Apache is definitly not the > problem here. > > Apache is a tool, a tool that shows us that we need to cooperate in order > to make progress. You can switch to git, and fork all you like, like so > many other projects. But then you have a few forks, sitting stale on > github. With sometimes an individual caring about it, or more times not. > Apache goes beyond individuals, and currently it shows we haven't made that > step. > > G. Simon > > -- > QCG, Software development, 071-5890970, http://www.qcg.nl > Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397 >
