Are we changing the minimum supported Java version for user code? If so,
we definitely need to change the major version number.
Even if we are not changing Java versions, I feel the volume of change
calls for a new major version number, even if each individual change
would not.
On 7/6/2016 3:26 AM, Peter wrote:
I know, thankfully that failure wasn't hard to track down and fix,
hopefully no more blocking issues arise, I like to have a full
weekend to generate release artifacts, run tests and rat reports.
There's an occassional bug in classdep that causes failures so you
have to test every build to make sure all's well.
We can move to git after the release, for now though, there's no harm
asking about the possibility of migrating.
I suppose we could just leave the version at 3.0.0 instead of
changing it to 2.3.0? There are no breaking changes, so it's non
compliant with agreed versioning, but it would avoid a lot of updates
to JIRA.
Regards,
Peter.
Sent from my Samsung device.
Include original message ---- Original message ---- From: Patricia
Shanahan <p...@acm.org> Sent: 06/07/2016 06:59:14 pm To:
dev@river.apache.org Subject: Re: Attic? Was: Re: Lotj - languages
other than java
I just hope a move to git does not become yet another reason to delay
a release. A few months ago we were really close - just a matter of
fixing a qa build failure.
On 7/5/2016 11:44 PM, Peter wrote:
Thanks Brian,
Hang in there, I think we can get back on track without
fragmenting, I've seen the developers on this project work well
together in the past. I do agree GitHub is less work for releases,
I'm going to attempt to get access to Apache's git wip repository.
My experience has been that much more communication occurs on
Apache River mail lists. The traffic I get with my fork on GitHub
relates to input validation for deserialization.
Regards,
Peter.
On 5/07/2016 12:49 AM, Bryan Thompson wrote:
I am just not that familiar with Apache policy. However, river
is a real, functional, deployed in use platform. I certainly
agree that there is deadlock at this point in terms of the people
and process. However, I am not sure that an attic is the right
place for a well grounded and fielded technology. While the
community might not be able to move ahead along a clear roadmap,
there is still support from the community for the technology.
Maybe a move to github would help to break things loose? Open up
the development and release process more? Right now things are
hung up in part on Apache process. Maybe Apache is just not the
right place at this time for this technology?
Thanks, Bryan
On Mon, Jul 4, 2016 at 10:08 AM, Patricia Shanahan<p...@acm.org>
wrote:
I think it is time to raise on the user list moving River to
the attic.
There is no sign of progress on a release. What interest there
is in development seems to be going in different directions.
Using portions of River code in other projects would still be
feasible with it in the attic, but there would be no need for a
PMC, and board reports.
Patricia
On 7/4/2016 6:44 AM, Simon IJskes - QCG wrote: ...
But then again, there are a lot of people reading this, and a
big part of them having no interest at all in incompatible
improvements, and i see no other option than leaving them
behind, with a jini compatible maintenance release. This will
certainly tear the river community apart, or at least cause a
lot of friction. So when i see only the two of us, moving in
a new direction, i can't help feeling, what is the use of it
all.
G. Simon
