Actually the org.apache.river namespace change should be sufficient to justify 
it.  Even though it isn't public api, people use these packages and it's  a 
breaking change.  To be honest I'm surprised it got through without any 
arguments.

Regards,

Peter.

Sent from my Samsung device.
 
  Include original message
---- Original message ----
From: Patricia Shanahan <p...@acm.org>
Sent: 06/07/2016 08:36:37 pm
To: dev@river.apache.org
Subject: Re: Attic? Was: Re: Lotj - languages other than java

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

Reply via email to