You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Benedikt Ritter <br...@apache.org> on 2013/10/09 21:17:32 UTC
[DISCUSS] Putting several unmaintained components to dormant
Hi,
I think Phil came up with the idea to try to focus on the components that
we are able to maintain and put all other stuff to dormant. Here is the
list of components that I think really are proper:
- CLI
- Codec
- Collections
- Compress
- Configuration
- CSV
- Daemon
- DBCP (?)
- Email
- Functor
- Imaging (?)
- IO
- JCI
- Lang
- Logging
- Math
- Net
- Pool (?)
- Proxy
- SCXML (after recent interest)
- VFS
- Weaver
All other stuff can go dormant because there is currently nobody who
maintains it. Still a pretty long list. Thoughts? Anything missing?
Benedikt
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Re: [DISCUSS] Putting several unmaintained components to dormant
Posted by Phil Steitz <ph...@gmail.com>.
On 10/9/13 12:17 PM, Benedikt Ritter wrote:
> Hi,
>
> I think Phil came up with the idea to try to focus on the components that
> we are able to maintain and put all other stuff to dormant. Here is the
> list of components that I think really are proper:
>
> - CLI
> - Codec
> - Collections
> - Compress
> - Configuration
> - CSV
> - Daemon
> - DBCP (?)
> - Email
> - Functor
> - Imaging (?)
> - IO
> - JCI
> - Lang
> - Logging
> - Math
> - Net
> - Pool (?)
> - Proxy
> - SCXML (after recent interest)
> - VFS
> - Weaver
>
> All other stuff can go dormant because there is currently nobody who
> maintains it. Still a pretty long list. Thoughts? Anything missing?
>
> Benedikt
>
Thanks, Benedikt! Beat me to it :)
That is a decent set to start with, which should be pared down,
IMO. One thing we have done in the past is to poll committers about
intention to work on stuff. I think [1] was originally created as
part of one attempt at this. I think intention among volunteers to
actually do work is more important than other signs of "activity" so
I suggest we either revive that page or just have people respond to
this thread indicating which components they intend to work on over
the next few months. Things with one vote are questionable, 2 or
more, "alive," others "dormant." I would say anyone can vote
(Commons committer or not), but voting should mean willingness to
put material effort into the thing.
I just updated [1] for me. The things I will be active on in the
near term (though at my normal snail's pace) are [math], [pool],
[dbcp].
Phil
[1] https://wiki.apache.org/commons/CommonsPeople
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Putting several unmaintained components to dormant
Posted by Matt Benson <gu...@gmail.com>.
Agreed, there are folks working on [pool] and [dbcp] pretty recently, Mark
Thomas and Bill Speirs off the top of my head.
Matt
On Wed, Oct 9, 2013 at 2:51 PM, Romain Manni-Bucau <rm...@gmail.com>wrote:
> Pool and dbcp sounds ok for proper imo
> Le 9 oct. 2013 21:20, "Dan Tran" <da...@gmail.com> a écrit :
>
> > VFS has no release for a couple of years. Would you consider it as
> proper?
> >
> > -D
> >
> >
> > On Wed, Oct 9, 2013 at 12:17 PM, Benedikt Ritter <br...@apache.org>
> > wrote:
> >
> > > Hi,
> > >
> > > I think Phil came up with the idea to try to focus on the components
> that
> > > we are able to maintain and put all other stuff to dormant. Here is the
> > > list of components that I think really are proper:
> > >
> > > - CLI
> > > - Codec
> > > - Collections
> > > - Compress
> > > - Configuration
> > > - CSV
> > > - Daemon
> > > - DBCP (?)
> > > - Email
> > > - Functor
> > > - Imaging (?)
> > > - IO
> > > - JCI
> > > - Lang
> > > - Logging
> > > - Math
> > > - Net
> > > - Pool (?)
> > > - Proxy
> > > - SCXML (after recent interest)
> > > - VFS
> > > - Weaver
> > >
> > > All other stuff can go dormant because there is currently nobody who
> > > maintains it. Still a pretty long list. Thoughts? Anything missing?
> > >
> > > Benedikt
> > >
> > > --
> > > http://people.apache.org/~britter/
> > > http://www.systemoutprintln.de/
> > > http://twitter.com/BenediktRitter
> > > http://github.com/britter
> > >
> >
>
Re: [DISCUSS] Putting several unmaintained components to dormant
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Pool and dbcp sounds ok for proper imo
Le 9 oct. 2013 21:20, "Dan Tran" <da...@gmail.com> a écrit :
> VFS has no release for a couple of years. Would you consider it as proper?
>
> -D
>
>
> On Wed, Oct 9, 2013 at 12:17 PM, Benedikt Ritter <br...@apache.org>
> wrote:
>
> > Hi,
> >
> > I think Phil came up with the idea to try to focus on the components that
> > we are able to maintain and put all other stuff to dormant. Here is the
> > list of components that I think really are proper:
> >
> > - CLI
> > - Codec
> > - Collections
> > - Compress
> > - Configuration
> > - CSV
> > - Daemon
> > - DBCP (?)
> > - Email
> > - Functor
> > - Imaging (?)
> > - IO
> > - JCI
> > - Lang
> > - Logging
> > - Math
> > - Net
> > - Pool (?)
> > - Proxy
> > - SCXML (after recent interest)
> > - VFS
> > - Weaver
> >
> > All other stuff can go dormant because there is currently nobody who
> > maintains it. Still a pretty long list. Thoughts? Anything missing?
> >
> > Benedikt
> >
> > --
> > http://people.apache.org/~britter/
> > http://www.systemoutprintln.de/
> > http://twitter.com/BenediktRitter
> > http://github.com/britter
> >
>
Re: [SCXML] Next major version number required package rename needed?
Posted by Benedikt Ritter <br...@apache.org>.
2013/10/11 Ate Douma <at...@douma.nu>
> On 10/11/2013 02:54 AM, James Carman wrote:
>
>> It wouldn't look so funky that way. I'm cool with that.
>>
>
> I'm leaning to this solution as well, going for scxml2 with version
> 2.0(-xx).
>
> While this would 'skip' the 1.0 range, I think not only doesn't it look so
> funky (scxml1) but also better indicate align with the current versioning
> rules
> which state that a first version should start with 1.0 to begin with.
> SCXML clearly was started long before this became practice, hence its
> current 0.x range.
> But as we're about to 'restart' the component, using version 2.0 probably
> is a beter indication of this 'second major version' for SCXML.
>
> If nobody further objects to this, I'll assume lazy consensus on this.
>
+1, let's do a 2.0
>
> Thank you all for the feedback,
Thanks you for pushing this forward!
>
> Ate
>
>
>
>> On Thursday, October 10, 2013, Niall Pemberton wrote:
>>
>> I would bump to version 2.0 because I dont think its clear that going
>>> from
>>> 0.9 to 1.0 is a major version change - in my mind 0.9 seems to imply "we
>>> haven't quite completed everything we want to for 1.0"
>>>
>>> Niall
>>>
>>>
>>> On Fri, Oct 11, 2013 at 12:52 AM, James Carman
>>> <james@carmanconsulting.com <javascript:;>>wrote:
>>>
>>> Now, this case is a bit weird, since we have released code in a < 1.0
>>>> version number. So, the artifact/package will have to be scxml1,
>>>> which looks funky IMHO. I guess that follows the pattern, though.
>>>>
>>>> On Thu, Oct 10, 2013 at 7:49 PM, Ate Douma <at...@douma.nu> wrote:
>>>>
>>>>> On 10/11/2013 01:41 AM, James Carman wrote:
>>>>>
>>>>>>
>>>>>> If you are breaking backward compatibility then you need to do the
>>>>>>
>>>>> renames
>>>>
>>>>> (package, and artifactId).
>>>>>>
>>>>>
>>>>>
>>>>> That was my impression already.
>>>>> And I have no real issue with doing so.
>>>>>
>>>>> But again, when has this been decided and has it ever been formalized
>>>>> (written down) somewhere?
>>>>>
>>>>>
>>>>>
>>>>>> I don't know if we ever landed on a "rule" about the new JDK level
>>>>>> scenario, though.
>>>>>>
>>>>>
>>>>> Okay, maybe that was just an incorrect assumption.
>>>>>
>>>>> And it doesn't really matter as there will be breaking API changes
>>>>>
>>>> needed
>>>
>>>> for the next version of SCXML, so we'll have to bump the major version
>>>>> anyway.
>>>>>
>>>>>
>>>>>> On Thursday, October 10, 2013, Ate Douma wrote:
>>>>>>
>>>>>> On 10/11/2013 01:16 AM, Emmanuel Bourg wrote:
>>>>>>>
>>>>>>> Commons SCXML has only one reverse dependency in Maven Central,
>>>>>>>> flexistate, so I wouldn't bother with the binary compatibility and
>>>>>>>>
>>>>>>> just
>>>>
>>>>> keep the package as is.
>>>>>>>>
>>>>>>>>
>>>>>>> Hmm. That might be the only reverse dependency of artifacts also
>>>>>>>
>>>>>> deployed
>>>>
>>>>> to Maven Central, but I'm pretty sure SCXML 0.9 is used in plenty of
>>>>>>> projects which might be impacted still.
>>>>>>>
>>>>>>> I would expect stronger arguments to decide yes/no if a package
>>>>>>>
>>>>>> rename
>>>
>>>> is
>>>>
>>>>> required or not. This would seem a bit (too) arbitrary to me.
>>>>>>>
>>>>>>> Mind you, I'd prefer not having to do a package rename, but I got the
>>>>>>> impression there are more explicit 'rules' when to do so.
>>>>>>>
>>>>>>> So I'd still would like to hear more explicitly if such a rule is
>>>>>>> defined,
>>>>>>> and if so how it is worded and where. But of course if there is none,
>>>>>>> fine
>>>>>>> by me :)
>>>>>>>
>>>>>>> Thanks, Ate
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> http://mvnrepository.com/****artifact/commons-scxml/****
>>> commons-scxml/0.9<http://mvnrepository.com/**artifact/commons-scxml/**commons-scxml/0.9>
>>>
>>>> <http://mvnrepository.com/**artifact/commons-scxml/**commons-scxml/0.9<http://mvnrepository.com/artifact/commons-scxml/commons-scxml/0.9>
>>>> >
>>>>
>>>>>
>>>>>>>> Emmanuel Bourg
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ------------------------------****----------------------------**
>>>> --**---------
>>>>
>>>>>
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<de...@commons.apache.org>
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ------------------------------****----------------------------**
>>>> --**---------
>>>>
>>>>>
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<de...@commons.apache.org>
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> ------------------------------**------------------------------**
>>>>> ---------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<de...@commons.apache.org>
>>>>> For additional commands, e-
>>>>>
>>>>
>>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<de...@commons.apache.org>
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Re: [SCXML] Next major version number required package rename needed?
Posted by Ate Douma <at...@douma.nu>.
On 10/11/2013 02:54 AM, James Carman wrote:
> It wouldn't look so funky that way. I'm cool with that.
I'm leaning to this solution as well, going for scxml2 with version 2.0(-xx).
While this would 'skip' the 1.0 range, I think not only doesn't it look so
funky (scxml1) but also better indicate align with the current versioning rules
which state that a first version should start with 1.0 to begin with.
SCXML clearly was started long before this became practice, hence its current
0.x range.
But as we're about to 'restart' the component, using version 2.0 probably is a
beter indication of this 'second major version' for SCXML.
If nobody further objects to this, I'll assume lazy consensus on this.
Thank you all for the feedback,
Ate
>
> On Thursday, October 10, 2013, Niall Pemberton wrote:
>
>> I would bump to version 2.0 because I dont think its clear that going from
>> 0.9 to 1.0 is a major version change - in my mind 0.9 seems to imply "we
>> haven't quite completed everything we want to for 1.0"
>>
>> Niall
>>
>>
>> On Fri, Oct 11, 2013 at 12:52 AM, James Carman
>> <james@carmanconsulting.com <javascript:;>>wrote:
>>
>>> Now, this case is a bit weird, since we have released code in a < 1.0
>>> version number. So, the artifact/package will have to be scxml1,
>>> which looks funky IMHO. I guess that follows the pattern, though.
>>>
>>> On Thu, Oct 10, 2013 at 7:49 PM, Ate Douma <at...@douma.nu> wrote:
>>>> On 10/11/2013 01:41 AM, James Carman wrote:
>>>>>
>>>>> If you are breaking backward compatibility then you need to do the
>>> renames
>>>>> (package, and artifactId).
>>>>
>>>>
>>>> That was my impression already.
>>>> And I have no real issue with doing so.
>>>>
>>>> But again, when has this been decided and has it ever been formalized
>>>> (written down) somewhere?
>>>>
>>>>
>>>>>
>>>>> I don't know if we ever landed on a "rule" about the new JDK level
>>>>> scenario, though.
>>>>
>>>> Okay, maybe that was just an incorrect assumption.
>>>>
>>>> And it doesn't really matter as there will be breaking API changes
>> needed
>>>> for the next version of SCXML, so we'll have to bump the major version
>>>> anyway.
>>>>
>>>>>
>>>>> On Thursday, October 10, 2013, Ate Douma wrote:
>>>>>
>>>>>> On 10/11/2013 01:16 AM, Emmanuel Bourg wrote:
>>>>>>
>>>>>>> Commons SCXML has only one reverse dependency in Maven Central,
>>>>>>> flexistate, so I wouldn't bother with the binary compatibility and
>>> just
>>>>>>> keep the package as is.
>>>>>>>
>>>>>>
>>>>>> Hmm. That might be the only reverse dependency of artifacts also
>>> deployed
>>>>>> to Maven Central, but I'm pretty sure SCXML 0.9 is used in plenty of
>>>>>> projects which might be impacted still.
>>>>>>
>>>>>> I would expect stronger arguments to decide yes/no if a package
>> rename
>>> is
>>>>>> required or not. This would seem a bit (too) arbitrary to me.
>>>>>>
>>>>>> Mind you, I'd prefer not having to do a package rename, but I got the
>>>>>> impression there are more explicit 'rules' when to do so.
>>>>>>
>>>>>> So I'd still would like to hear more explicitly if such a rule is
>>>>>> defined,
>>>>>> and if so how it is worded and where. But of course if there is none,
>>>>>> fine
>>>>>> by me :)
>>>>>>
>>>>>> Thanks, Ate
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>> http://mvnrepository.com/**artifact/commons-scxml/**commons-scxml/0.9
>>> <http://mvnrepository.com/artifact/commons-scxml/commons-scxml/0.9>
>>>>>>>
>>>>>>> Emmanuel Bourg
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>> ------------------------------**------------------------------**---------
>>>>>>>
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>> ------------------------------**------------------------------**---------
>>>>>>
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [SCXML] Next major version number required package rename needed?
Posted by James Carman <ja...@carmanconsulting.com>.
It wouldn't look so funky that way. I'm cool with that.
On Thursday, October 10, 2013, Niall Pemberton wrote:
> I would bump to version 2.0 because I dont think its clear that going from
> 0.9 to 1.0 is a major version change - in my mind 0.9 seems to imply "we
> haven't quite completed everything we want to for 1.0"
>
> Niall
>
>
> On Fri, Oct 11, 2013 at 12:52 AM, James Carman
> <james@carmanconsulting.com <javascript:;>>wrote:
>
> > Now, this case is a bit weird, since we have released code in a < 1.0
> > version number. So, the artifact/package will have to be scxml1,
> > which looks funky IMHO. I guess that follows the pattern, though.
> >
> > On Thu, Oct 10, 2013 at 7:49 PM, Ate Douma <at...@douma.nu> wrote:
> > > On 10/11/2013 01:41 AM, James Carman wrote:
> > >>
> > >> If you are breaking backward compatibility then you need to do the
> > renames
> > >> (package, and artifactId).
> > >
> > >
> > > That was my impression already.
> > > And I have no real issue with doing so.
> > >
> > > But again, when has this been decided and has it ever been formalized
> > > (written down) somewhere?
> > >
> > >
> > >>
> > >> I don't know if we ever landed on a "rule" about the new JDK level
> > >> scenario, though.
> > >
> > > Okay, maybe that was just an incorrect assumption.
> > >
> > > And it doesn't really matter as there will be breaking API changes
> needed
> > > for the next version of SCXML, so we'll have to bump the major version
> > > anyway.
> > >
> > >>
> > >> On Thursday, October 10, 2013, Ate Douma wrote:
> > >>
> > >>> On 10/11/2013 01:16 AM, Emmanuel Bourg wrote:
> > >>>
> > >>>> Commons SCXML has only one reverse dependency in Maven Central,
> > >>>> flexistate, so I wouldn't bother with the binary compatibility and
> > just
> > >>>> keep the package as is.
> > >>>>
> > >>>
> > >>> Hmm. That might be the only reverse dependency of artifacts also
> > deployed
> > >>> to Maven Central, but I'm pretty sure SCXML 0.9 is used in plenty of
> > >>> projects which might be impacted still.
> > >>>
> > >>> I would expect stronger arguments to decide yes/no if a package
> rename
> > is
> > >>> required or not. This would seem a bit (too) arbitrary to me.
> > >>>
> > >>> Mind you, I'd prefer not having to do a package rename, but I got the
> > >>> impression there are more explicit 'rules' when to do so.
> > >>>
> > >>> So I'd still would like to hear more explicitly if such a rule is
> > >>> defined,
> > >>> and if so how it is worded and where. But of course if there is none,
> > >>> fine
> > >>> by me :)
> > >>>
> > >>> Thanks, Ate
> > >>>
> > >>>
> > >>>>
> > >>>>
> http://mvnrepository.com/**artifact/commons-scxml/**commons-scxml/0.9
> > <http://mvnrepository.com/artifact/commons-scxml/commons-scxml/0.9>
> > >>>>
> > >>>> Emmanuel Bourg
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > ------------------------------**------------------------------**---------
> > >>>>
> > >>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > >>>> For additional commands, e-mail: dev-help@commons.apache.org
> > >>>>
> > >>>>
> > >>>
> > >>>
> > ------------------------------**------------------------------**---------
> > >>>
> > >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > >>> For additional commands, e-mail: dev-help@commons.apache.org
> > >>>
> > >>>
> > >>
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-
Re: [SCXML] Next major version number required package rename needed?
Posted by Matt Benson <gu...@gmail.com>.
I would also treat 0.9 as a "real release" and act accordingly wrt API
changes; the current release is far too old to do otherwise IMHO.
Matt
On Oct 10, 2013 7:41 PM, "Niall Pemberton" <ni...@gmail.com>
wrote:
> I would bump to version 2.0 because I dont think its clear that going from
> 0.9 to 1.0 is a major version change - in my mind 0.9 seems to imply "we
> haven't quite completed everything we want to for 1.0"
>
> Niall
>
>
> On Fri, Oct 11, 2013 at 12:52 AM, James Carman
> <ja...@carmanconsulting.com>wrote:
>
> > Now, this case is a bit weird, since we have released code in a < 1.0
> > version number. So, the artifact/package will have to be scxml1,
> > which looks funky IMHO. I guess that follows the pattern, though.
> >
> > On Thu, Oct 10, 2013 at 7:49 PM, Ate Douma <at...@douma.nu> wrote:
> > > On 10/11/2013 01:41 AM, James Carman wrote:
> > >>
> > >> If you are breaking backward compatibility then you need to do the
> > renames
> > >> (package, and artifactId).
> > >
> > >
> > > That was my impression already.
> > > And I have no real issue with doing so.
> > >
> > > But again, when has this been decided and has it ever been formalized
> > > (written down) somewhere?
> > >
> > >
> > >>
> > >> I don't know if we ever landed on a "rule" about the new JDK level
> > >> scenario, though.
> > >
> > > Okay, maybe that was just an incorrect assumption.
> > >
> > > And it doesn't really matter as there will be breaking API changes
> needed
> > > for the next version of SCXML, so we'll have to bump the major version
> > > anyway.
> > >
> > >>
> > >> On Thursday, October 10, 2013, Ate Douma wrote:
> > >>
> > >>> On 10/11/2013 01:16 AM, Emmanuel Bourg wrote:
> > >>>
> > >>>> Commons SCXML has only one reverse dependency in Maven Central,
> > >>>> flexistate, so I wouldn't bother with the binary compatibility and
> > just
> > >>>> keep the package as is.
> > >>>>
> > >>>
> > >>> Hmm. That might be the only reverse dependency of artifacts also
> > deployed
> > >>> to Maven Central, but I'm pretty sure SCXML 0.9 is used in plenty of
> > >>> projects which might be impacted still.
> > >>>
> > >>> I would expect stronger arguments to decide yes/no if a package
> rename
> > is
> > >>> required or not. This would seem a bit (too) arbitrary to me.
> > >>>
> > >>> Mind you, I'd prefer not having to do a package rename, but I got the
> > >>> impression there are more explicit 'rules' when to do so.
> > >>>
> > >>> So I'd still would like to hear more explicitly if such a rule is
> > >>> defined,
> > >>> and if so how it is worded and where. But of course if there is none,
> > >>> fine
> > >>> by me :)
> > >>>
> > >>> Thanks, Ate
> > >>>
> > >>>
> > >>>>
> > >>>>
> http://mvnrepository.com/**artifact/commons-scxml/**commons-scxml/0.9
> > <http://mvnrepository.com/artifact/commons-scxml/commons-scxml/0.9>
> > >>>>
> > >>>> Emmanuel Bourg
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > ------------------------------**------------------------------**---------
> > >>>>
> > >>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > >>>> For additional commands, e-mail: dev-help@commons.apache.org
> > >>>>
> > >>>>
> > >>>
> > >>>
> > ------------------------------**------------------------------**---------
> > >>>
> > >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > >>> For additional commands, e-mail: dev-help@commons.apache.org
> > >>>
> > >>>
> > >>
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
Re: [SCXML] Next major version number required package rename needed?
Posted by Paul Benedict <pb...@apache.org>.
The dots aren't decimal separators and version numbers are not true
numbers. 0.9 goes to 0.10 goes to 0.11, etc. If they were true decimal
numbers, you couldn't have more than one dot.
0.9 to 1.0 is a major version jump. However, 0.X usually indicates
pre-release quality (i.e., not ready for production yet).
Paul
On Thu, Oct 10, 2013 at 7:40 PM, Niall Pemberton
<ni...@gmail.com>wrote:
> I would bump to version 2.0 because I dont think its clear that going from
> 0.9 to 1.0 is a major version change - in my mind 0.9 seems to imply "we
> haven't quite completed everything we want to for 1.0"
>
> Niall
>
>
> On Fri, Oct 11, 2013 at 12:52 AM, James Carman
> <ja...@carmanconsulting.com>wrote:
>
> > Now, this case is a bit weird, since we have released code in a < 1.0
> > version number. So, the artifact/package will have to be scxml1,
> > which looks funky IMHO. I guess that follows the pattern, though.
> >
> > On Thu, Oct 10, 2013 at 7:49 PM, Ate Douma <at...@douma.nu> wrote:
> > > On 10/11/2013 01:41 AM, James Carman wrote:
> > >>
> > >> If you are breaking backward compatibility then you need to do the
> > renames
> > >> (package, and artifactId).
> > >
> > >
> > > That was my impression already.
> > > And I have no real issue with doing so.
> > >
> > > But again, when has this been decided and has it ever been formalized
> > > (written down) somewhere?
> > >
> > >
> > >>
> > >> I don't know if we ever landed on a "rule" about the new JDK level
> > >> scenario, though.
> > >
> > > Okay, maybe that was just an incorrect assumption.
> > >
> > > And it doesn't really matter as there will be breaking API changes
> needed
> > > for the next version of SCXML, so we'll have to bump the major version
> > > anyway.
> > >
> > >>
> > >> On Thursday, October 10, 2013, Ate Douma wrote:
> > >>
> > >>> On 10/11/2013 01:16 AM, Emmanuel Bourg wrote:
> > >>>
> > >>>> Commons SCXML has only one reverse dependency in Maven Central,
> > >>>> flexistate, so I wouldn't bother with the binary compatibility and
> > just
> > >>>> keep the package as is.
> > >>>>
> > >>>
> > >>> Hmm. That might be the only reverse dependency of artifacts also
> > deployed
> > >>> to Maven Central, but I'm pretty sure SCXML 0.9 is used in plenty of
> > >>> projects which might be impacted still.
> > >>>
> > >>> I would expect stronger arguments to decide yes/no if a package
> rename
> > is
> > >>> required or not. This would seem a bit (too) arbitrary to me.
> > >>>
> > >>> Mind you, I'd prefer not having to do a package rename, but I got the
> > >>> impression there are more explicit 'rules' when to do so.
> > >>>
> > >>> So I'd still would like to hear more explicitly if such a rule is
> > >>> defined,
> > >>> and if so how it is worded and where. But of course if there is none,
> > >>> fine
> > >>> by me :)
> > >>>
> > >>> Thanks, Ate
> > >>>
> > >>>
> > >>>>
> > >>>>
> http://mvnrepository.com/**artifact/commons-scxml/**commons-scxml/0.9
> > <http://mvnrepository.com/artifact/commons-scxml/commons-scxml/0.9>
> > >>>>
> > >>>> Emmanuel Bourg
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > ------------------------------**------------------------------**---------
> > >>>>
> > >>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > >>>> For additional commands, e-mail: dev-help@commons.apache.org
> > >>>>
> > >>>>
> > >>>
> > >>>
> > ------------------------------**------------------------------**---------
> > >>>
> > >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > >>> For additional commands, e-mail: dev-help@commons.apache.org
> > >>>
> > >>>
> > >>
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
--
Cheers,
Paul
Re: [SCXML] Next major version number required package rename needed?
Posted by Niall Pemberton <ni...@gmail.com>.
I would bump to version 2.0 because I dont think its clear that going from
0.9 to 1.0 is a major version change - in my mind 0.9 seems to imply "we
haven't quite completed everything we want to for 1.0"
Niall
On Fri, Oct 11, 2013 at 12:52 AM, James Carman
<ja...@carmanconsulting.com>wrote:
> Now, this case is a bit weird, since we have released code in a < 1.0
> version number. So, the artifact/package will have to be scxml1,
> which looks funky IMHO. I guess that follows the pattern, though.
>
> On Thu, Oct 10, 2013 at 7:49 PM, Ate Douma <at...@douma.nu> wrote:
> > On 10/11/2013 01:41 AM, James Carman wrote:
> >>
> >> If you are breaking backward compatibility then you need to do the
> renames
> >> (package, and artifactId).
> >
> >
> > That was my impression already.
> > And I have no real issue with doing so.
> >
> > But again, when has this been decided and has it ever been formalized
> > (written down) somewhere?
> >
> >
> >>
> >> I don't know if we ever landed on a "rule" about the new JDK level
> >> scenario, though.
> >
> > Okay, maybe that was just an incorrect assumption.
> >
> > And it doesn't really matter as there will be breaking API changes needed
> > for the next version of SCXML, so we'll have to bump the major version
> > anyway.
> >
> >>
> >> On Thursday, October 10, 2013, Ate Douma wrote:
> >>
> >>> On 10/11/2013 01:16 AM, Emmanuel Bourg wrote:
> >>>
> >>>> Commons SCXML has only one reverse dependency in Maven Central,
> >>>> flexistate, so I wouldn't bother with the binary compatibility and
> just
> >>>> keep the package as is.
> >>>>
> >>>
> >>> Hmm. That might be the only reverse dependency of artifacts also
> deployed
> >>> to Maven Central, but I'm pretty sure SCXML 0.9 is used in plenty of
> >>> projects which might be impacted still.
> >>>
> >>> I would expect stronger arguments to decide yes/no if a package rename
> is
> >>> required or not. This would seem a bit (too) arbitrary to me.
> >>>
> >>> Mind you, I'd prefer not having to do a package rename, but I got the
> >>> impression there are more explicit 'rules' when to do so.
> >>>
> >>> So I'd still would like to hear more explicitly if such a rule is
> >>> defined,
> >>> and if so how it is worded and where. But of course if there is none,
> >>> fine
> >>> by me :)
> >>>
> >>> Thanks, Ate
> >>>
> >>>
> >>>>
> >>>> http://mvnrepository.com/**artifact/commons-scxml/**commons-scxml/0.9
> <http://mvnrepository.com/artifact/commons-scxml/commons-scxml/0.9>
> >>>>
> >>>> Emmanuel Bourg
> >>>>
> >>>>
> >>>>
> >>>>
> ------------------------------**------------------------------**---------
> >>>>
> >>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>
> >>>>
> >>>
> >>>
> ------------------------------**------------------------------**---------
> >>>
> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>
> >>>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [SCXML] Next major version number required package rename needed?
Posted by James Carman <ja...@carmanconsulting.com>.
Now, this case is a bit weird, since we have released code in a < 1.0
version number. So, the artifact/package will have to be scxml1,
which looks funky IMHO. I guess that follows the pattern, though.
On Thu, Oct 10, 2013 at 7:49 PM, Ate Douma <at...@douma.nu> wrote:
> On 10/11/2013 01:41 AM, James Carman wrote:
>>
>> If you are breaking backward compatibility then you need to do the renames
>> (package, and artifactId).
>
>
> That was my impression already.
> And I have no real issue with doing so.
>
> But again, when has this been decided and has it ever been formalized
> (written down) somewhere?
>
>
>>
>> I don't know if we ever landed on a "rule" about the new JDK level
>> scenario, though.
>
> Okay, maybe that was just an incorrect assumption.
>
> And it doesn't really matter as there will be breaking API changes needed
> for the next version of SCXML, so we'll have to bump the major version
> anyway.
>
>>
>> On Thursday, October 10, 2013, Ate Douma wrote:
>>
>>> On 10/11/2013 01:16 AM, Emmanuel Bourg wrote:
>>>
>>>> Commons SCXML has only one reverse dependency in Maven Central,
>>>> flexistate, so I wouldn't bother with the binary compatibility and just
>>>> keep the package as is.
>>>>
>>>
>>> Hmm. That might be the only reverse dependency of artifacts also deployed
>>> to Maven Central, but I'm pretty sure SCXML 0.9 is used in plenty of
>>> projects which might be impacted still.
>>>
>>> I would expect stronger arguments to decide yes/no if a package rename is
>>> required or not. This would seem a bit (too) arbitrary to me.
>>>
>>> Mind you, I'd prefer not having to do a package rename, but I got the
>>> impression there are more explicit 'rules' when to do so.
>>>
>>> So I'd still would like to hear more explicitly if such a rule is
>>> defined,
>>> and if so how it is worded and where. But of course if there is none,
>>> fine
>>> by me :)
>>>
>>> Thanks, Ate
>>>
>>>
>>>>
>>>> http://mvnrepository.com/**artifact/commons-scxml/**commons-scxml/0.9<http://mvnrepository.com/artifact/commons-scxml/commons-scxml/0.9>
>>>>
>>>> Emmanuel Bourg
>>>>
>>>>
>>>>
>>>> ------------------------------**------------------------------**---------
>>>>
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>> ------------------------------**------------------------------**---------
>>>
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [SCXML] Next major version number required package rename needed?
Posted by Ate Douma <at...@douma.nu>.
On 10/11/2013 01:41 AM, James Carman wrote:
> If you are breaking backward compatibility then you need to do the renames
> (package, and artifactId).
That was my impression already.
And I have no real issue with doing so.
But again, when has this been decided and has it ever been formalized (written
down) somewhere?
>
> I don't know if we ever landed on a "rule" about the new JDK level
> scenario, though.
Okay, maybe that was just an incorrect assumption.
And it doesn't really matter as there will be breaking API changes needed for
the next version of SCXML, so we'll have to bump the major version anyway.
>
> On Thursday, October 10, 2013, Ate Douma wrote:
>
>> On 10/11/2013 01:16 AM, Emmanuel Bourg wrote:
>>
>>> Commons SCXML has only one reverse dependency in Maven Central,
>>> flexistate, so I wouldn't bother with the binary compatibility and just
>>> keep the package as is.
>>>
>>
>> Hmm. That might be the only reverse dependency of artifacts also deployed
>> to Maven Central, but I'm pretty sure SCXML 0.9 is used in plenty of
>> projects which might be impacted still.
>>
>> I would expect stronger arguments to decide yes/no if a package rename is
>> required or not. This would seem a bit (too) arbitrary to me.
>>
>> Mind you, I'd prefer not having to do a package rename, but I got the
>> impression there are more explicit 'rules' when to do so.
>>
>> So I'd still would like to hear more explicitly if such a rule is defined,
>> and if so how it is worded and where. But of course if there is none, fine
>> by me :)
>>
>> Thanks, Ate
>>
>>
>>> http://mvnrepository.com/**artifact/commons-scxml/**commons-scxml/0.9<http://mvnrepository.com/artifact/commons-scxml/commons-scxml/0.9>
>>>
>>> Emmanuel Bourg
>>>
>>>
>>> ------------------------------**------------------------------**---------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
[SCXML] Next major version number required package rename needed?
Posted by James Carman <ja...@carmanconsulting.com>.
If you are breaking backward compatibility then you need to do the renames
(package, and artifactId).
I don't know if we ever landed on a "rule" about the new JDK level
scenario, though.
On Thursday, October 10, 2013, Ate Douma wrote:
> On 10/11/2013 01:16 AM, Emmanuel Bourg wrote:
>
>> Commons SCXML has only one reverse dependency in Maven Central,
>> flexistate, so I wouldn't bother with the binary compatibility and just
>> keep the package as is.
>>
>
> Hmm. That might be the only reverse dependency of artifacts also deployed
> to Maven Central, but I'm pretty sure SCXML 0.9 is used in plenty of
> projects which might be impacted still.
>
> I would expect stronger arguments to decide yes/no if a package rename is
> required or not. This would seem a bit (too) arbitrary to me.
>
> Mind you, I'd prefer not having to do a package rename, but I got the
> impression there are more explicit 'rules' when to do so.
>
> So I'd still would like to hear more explicitly if such a rule is defined,
> and if so how it is worded and where. But of course if there is none, fine
> by me :)
>
> Thanks, Ate
>
>
>> http://mvnrepository.com/**artifact/commons-scxml/**commons-scxml/0.9<http://mvnrepository.com/artifact/commons-scxml/commons-scxml/0.9>
>>
>> Emmanuel Bourg
>>
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [SCXML] Next major version number required package rename needed?
Posted by Ate Douma <at...@douma.nu>.
On 10/11/2013 01:16 AM, Emmanuel Bourg wrote:
> Commons SCXML has only one reverse dependency in Maven Central,
> flexistate, so I wouldn't bother with the binary compatibility and just
> keep the package as is.
Hmm. That might be the only reverse dependency of artifacts also deployed to
Maven Central, but I'm pretty sure SCXML 0.9 is used in plenty of projects which
might be impacted still.
I would expect stronger arguments to decide yes/no if a package rename is
required or not. This would seem a bit (too) arbitrary to me.
Mind you, I'd prefer not having to do a package rename, but I got the impression
there are more explicit 'rules' when to do so.
So I'd still would like to hear more explicitly if such a rule is defined, and
if so how it is worded and where. But of course if there is none, fine by me :)
Thanks, Ate
>
> http://mvnrepository.com/artifact/commons-scxml/commons-scxml/0.9
>
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [SCXML] Next major version number required package rename needed?
Posted by Emmanuel Bourg <eb...@apache.org>.
Commons SCXML has only one reverse dependency in Maven Central,
flexistate, so I wouldn't bother with the binary compatibility and just
keep the package as is.
http://mvnrepository.com/artifact/commons-scxml/commons-scxml/0.9
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
[SCXML] Next major version number required package rename needed?
Posted by Ate Douma <at...@douma.nu>.
On 10/10/2013 09:39 PM, Rahul Akolkar wrote:
> On Thu, Oct 10, 2013 at 7:26 AM, Ate Douma <at...@douma.nu> wrote:
<snip/>
>>
>> Case in point: SCXML
>> If we are allowed to start working on this component shortly, we intend to,
>> and HAVE to switch to a 1.0 version first, as there already is a 0.9 version
>> release out, while we will need to move to newer JDK and incompatible API
>> changes anyway. At the same time, getting a final/stabalized 1.0 release out
>> most certainly will take several iterations.
> <snip/>
>
> Release version comparisons being what the are, we could go to v0.10,
> as in below (greater than sign implies more recent release version):
>
> 0.11 > 0.10 > 0.9
For the intended promotion of the SCXML J6 branch to trunk, I don't think that
would align with the Commons versioning scheme.
The SCXML J6 branch (which currently already uses version 1.0-SNAPSHOT) imposes
API breaking changes from the 0.9 release, as well as targets a newer JDK (1.6+).
AFAIK this will require a major version bump, hence should target version 1.0.
I thus intend to roll out a first intermediate release of this new trunk as
version 1.0-alpha-1 (as discussed earlier today in a separate thread).
What however is still unclear to me is if this also requires a package rename,
e.g. move from org.apache.commons.scxml.* -> org.apache.commons.scxml1.* ?
I got the impression from other discussions as well as from looking at other
components recent major versions, that this now also is a rule or policy within
Commons. But I can't find any specific writing about such 'policy'.
At least the online Versioning document doesn't say anything about it, or I must
be blindly overlooking it.
So my question is: is such package rename now a required rule, or more of a
convention?
And if this was established as a formal requirement, can someone point me out
the documentation (or maybe VOTE thread) for it?
Thanks, Ate
>
> Not very different than, say the following, which may appear more
> intuitive for release versions (agree 0.x line is trickier):
>
> 2.11 > 2.10 > 2.9
>
> Overall, I think it's OK to go the 0.10 route, if you want to save a
> 1.0 major release for later at a point it's really needed.
>
> In hindsight, the first Commons SCXML release could've been 0.1
> (rather than 0.5) to give more room for 4 more releases before getting
> to this point :-)
>
> -Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases [Was:
[DISCUSS] Putting several unmaintained components to dormant]
Posted by Rahul Akolkar <ra...@gmail.com>.
On Thu, Oct 10, 2013 at 7:26 AM, Ate Douma <at...@douma.nu> wrote:
> I've move this into a separate [DISCUSS] thread as I think it needs separate
> discussion.
>
> Jörg gave some objections below about using Milestone releases, as I
> proposed earlier to support releasing intermediate versions of a
> not-yet-stabalized component.
>
> While I understand his problems with unstable versions potentially getting
> 'stuck' for long time, where end-users *might* start expecting them to
> remain stable, I don't agree this is, or should be, the common case. Or at
> least not an argument to hold against using such 0.x or -Milestone releases.
>
> Instead, the whole point is to get project/component development moving
> *faster* by allowing *experimental* end-users to provide feedback, and more
> flexibility and convenience for the developers of such project/component.
>
> The idea to have to 'switch' to a next major version for any incompatibile
> change, as Jörg proposes, requiring package changes, whatnot, while a
> project clearly is not ready to stabalize, really puts way too much hurdles
> up for both the developers *and* such experimental end-users, as they would
> HAVE to change all of their code to be able to provide AND leaverage such
> new 0.x or Milestone version.
>
> Case in point: SCXML
> If we are allowed to start working on this component shortly, we intend to,
> and HAVE to switch to a 1.0 version first, as there already is a 0.9 version
> release out, while we will need to move to newer JDK and incompatible API
> changes anyway. At the same time, getting a final/stabalized 1.0 release out
> most certainly will take several iterations.
<snip/>
Release version comparisons being what the are, we could go to v0.10,
as in below (greater than sign implies more recent release version):
0.11 > 0.10 > 0.9
Not very different than, say the following, which may appear more
intuitive for release versions (agree 0.x line is trickier):
2.11 > 2.10 > 2.9
Overall, I think it's OK to go the 0.10 route, if you want to save a
1.0 major release for later at a point it's really needed.
In hindsight, the first Commons SCXML release could've been 0.1
(rather than 0.5) to give more room for 4 more releases before getting
to this point :-)
-Rahul
> I don't want to have to wait doing an intermediate release, nor rapidly
> having to switch to a 2.x/3.x/4.x/etc. versions, just because Milestone
> releases are acceptable for this purpose. Where would Milestone releases [1]
> be useful for otherwise, anyway?
>
> I think a real problem might arise IF other components (or 3rd party
> libraries) would start depending directly on such Milestone releases,
> potentially introducing unexpected instabilities for end-users. And maybe it
> is worthwhile to make such usages, at least for Commons, prohibited. That
> would make sense to me.
>
> But for components like SCXML, javaflow, or csv, this I don't think would be
> a real issue. Those end-users making use of these experimental components
> are, or should be very well aware, of the added responsibility they take
> depending on a not-yet-stabilized version, as clearly is also indicated by
> the version, as well as SHOULD be prominently documented in the release
> notes, readme, etc.
>
> Thoughts?
>
> Ate
>
> On 10/10/2013 12:45 PM, Benedikt Ritter wrote:
>>
>> I like the idea of releasing 0.x versions. A good example is [csv]. I
>> would have no problem with releasing the current trunk as 0.9. At the moment
>> [csv] is just another component we don't releaese because we want to come up
>> with a perfect API (and I take responsibility for that :-)
>>
>> Benedikt
>>
>> Send from my mobile device
>>
>>> Am 10.10.2013 um 12:15 schrieb Jörg Schaible
>>> <Jo...@scalaris.com>:
>>>
>>> Hi,
>>>
>>> Ate Douma wrote:
>>>
>>>>> On 10/10/2013 12:24 AM, Torsten Curdt wrote:
>>>>> Every now and then I keep getting requests via private mail asking to
>>>>> release javaflow as it seems to be working for people. Yet I know there
>>>>> is still so much essential stuff to fix for a 1.0 release.
>>>>>
>>>>> Crossing over to the other thread: I know on github I would made a 0.x
>>>>> release already ages ago but knowing I won't have time to work on it
>>>>> anymore I keep pushing this out at commons.
>>>>
>>>>
>>>> Wouldn't this be a case to allow and use intermediate milestone
>>>> releases?
>>>>
>>>> Using a 1.0-Mxx version would make still clear to the users things
>>>> haven't
>>>> settled yet (API wise), so should not limit or restrict making API
>>>> changes
>>>> before a final 1.0 release, but would help both the community and the
>>>> project moving. More likely to incite further involvement and
>>>> contributions, etc.
>>>>
>>>> Being 'stuck' on getting a (final) 1.0 release out because everything
>>>> should be settled and 'frozen' (API wise) first doesn't make sense to me
>>>> at all.
>>>
>>>
>>> We should not be so afraid to switch to 2.x if the 1.x API turns out to
>>> be
>>> cumbersome in some cases. Typically you may also increase Java level in
>>> the
>>> meantime and therefore eventually even have a benefit of new
>>> possibilities.
>>>
>>>> "Release early and often" really is what keeps open source projects
>>>> moving
>>>> forward, *any* policy which blocks that is plain wrong and should be
>>>> fixed.
>>>>
>>>> Note: I'm not saying I'm against the strict versioning rules, but those
>>>> should NOT block getting to a 1.0 release easily.
>>>> And I don't think they do. Isn't this where Milestone releases are meant
>>>> for?
>>>
>>>
>>> I am not a big fan of milestones unless we really have a forced schedule
>>> for
>>> the final release. If we get into the situation that the milestone is the
>>> latest release for months, we get into jar hell again, because that
>>> milestone is then *used* like any proper release. You cannot prevent
>>> this.
>>>
>>> There is a reason why I have to use for a (private) Maven plugin an
>>> artifact
>>> like
>>> org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9-stable-1.
>>> That's a result of such a "milestone" and I really like to avoid this
>>> situation for Apache Commons.
>>>
>>>>> Release and put into dormant?
>>>>> It's a strange situation.
>>>
>>>
>>> No release it as 1.0 and go on with 2.x, since 1.0 is probably already
>>> based
>>> on old technology.
>>>
>>> - Jörg
>>>
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases [Was: [DISCUSS]
Putting several unmaintained components to dormant]
Posted by Ate Douma <at...@douma.nu>.
On 10/10/2013 03:31 PM, James Carman wrote:
> We definitely need to make sure our naming scheme will work with maven
> properly. Hopefully commons-foo:1.0 would supercede
> commons-foo:1.0-M1. Again, I really don't care what we call it, as
> long as we manage expectations and don't dork up maven.
Since Maven 3+ there is now a reasonable and predictable handling of such
versioning, including doing 'the right thing' for the commons-foo:1.0-M1 example.
See [1] (which is an old wiki proposal which since has been implemented) and [2]
for the exact rules, which I'm copying below for convenience.
From [2]:
Features:
- mixing of '-' (dash) and '.' (dot) separators,
- transition between characters and digits also constitutes a separator:
1.0alpha1 => [1, 0, alpha, 1]
- unlimited number of version components,
- version components in the text can be digits or strings,
- strings are checked for well-known qualifiers and the qualifier ordering is
used for version ordering. Well-known qualifiers (case insensitive) are:
- snapshot
- alpha or a
- beta or b
- milestone or m
- rc or cr
- (the empty string) or ga or final
- sp
Unknown qualifiers are considered after known qualifiers, with lexical
order (always case insensitive),
- a dash usually precedes a qualifier, and is always less important than
something preceded with a dot.
[1] https://cwiki.apache.org/confluence/display/MAVENOLD/Versioning
[2]
http://maven.apache.org/ref/3.0.4/maven-artifact/apidocs/org/apache/maven/artifact/versioning/ComparableVersion.html
>
> On Thu, Oct 10, 2013 at 9:25 AM, Ate Douma <at...@douma.nu> wrote:
>> On 10/10/2013 03:00 PM, James Carman wrote:
>>>
>>> On Thu, Oct 10, 2013 at 8:35 AM, Gary Gregory <ga...@gmail.com>
>>> wrote:
>>>>
>>>> I think "milestone" releases works if you have a clear development
>>>> plan and schedule. I've never seen it be the case in Commons. Calling
>>>> "releases" to Maven and dist, Alphas and Betas make more sense for us
>>>> IMO.
>>>>
>>>
>>> I don't care what we call it. They key is that we set up the
>>> expectation with our users. If you use this release, do NOT use it in
>>> production code. It is not "supported", meaning we aren't going to
>>> fix bugs in that alpha version if we have already released its
>>> subsequent full release version (or a subsequent alpha).
>>
>>
>> Indeed and agreed.
>>
>> I also don't care if its called milestone or alpha or whatever.
>> But we already have explicit wording for milestone releases [1], also
>> clearly stating such releases are not supported.
>>
>> So I'm actually only asking *confirmation* to use already established rules.
>>
>> [1] http://commons.apache.org/releases/versioning.html#Milestone_Releases
>>
>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases [Was:
[DISCUSS] Putting several unmaintained components to dormant]
Posted by James Carman <ja...@carmanconsulting.com>.
We definitely need to make sure our naming scheme will work with maven
properly. Hopefully commons-foo:1.0 would supercede
commons-foo:1.0-M1. Again, I really don't care what we call it, as
long as we manage expectations and don't dork up maven.
On Thu, Oct 10, 2013 at 9:25 AM, Ate Douma <at...@douma.nu> wrote:
> On 10/10/2013 03:00 PM, James Carman wrote:
>>
>> On Thu, Oct 10, 2013 at 8:35 AM, Gary Gregory <ga...@gmail.com>
>> wrote:
>>>
>>> I think "milestone" releases works if you have a clear development
>>> plan and schedule. I've never seen it be the case in Commons. Calling
>>> "releases" to Maven and dist, Alphas and Betas make more sense for us
>>> IMO.
>>>
>>
>> I don't care what we call it. They key is that we set up the
>> expectation with our users. If you use this release, do NOT use it in
>> production code. It is not "supported", meaning we aren't going to
>> fix bugs in that alpha version if we have already released its
>> subsequent full release version (or a subsequent alpha).
>
>
> Indeed and agreed.
>
> I also don't care if its called milestone or alpha or whatever.
> But we already have explicit wording for milestone releases [1], also
> clearly stating such releases are not supported.
>
> So I'm actually only asking *confirmation* to use already established rules.
>
> [1] http://commons.apache.org/releases/versioning.html#Milestone_Releases
>
>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases [Was: [DISCUSS]
Putting several unmaintained components to dormant]
Posted by Ate Douma <at...@douma.nu>.
On 10/10/2013 03:00 PM, James Carman wrote:
> On Thu, Oct 10, 2013 at 8:35 AM, Gary Gregory <ga...@gmail.com> wrote:
>> I think "milestone" releases works if you have a clear development
>> plan and schedule. I've never seen it be the case in Commons. Calling
>> "releases" to Maven and dist, Alphas and Betas make more sense for us
>> IMO.
>>
>
> I don't care what we call it. They key is that we set up the
> expectation with our users. If you use this release, do NOT use it in
> production code. It is not "supported", meaning we aren't going to
> fix bugs in that alpha version if we have already released its
> subsequent full release version (or a subsequent alpha).
Indeed and agreed.
I also don't care if its called milestone or alpha or whatever.
But we already have explicit wording for milestone releases [1], also clearly
stating such releases are not supported.
So I'm actually only asking *confirmation* to use already established rules.
[1] http://commons.apache.org/releases/versioning.html#Milestone_Releases
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases [Was:
[DISCUSS] Putting several unmaintained components to dormant]
Posted by Gary Gregory <ga...@gmail.com>.
On Thu, Oct 10, 2013 at 9:00 AM, James Carman
<ja...@carmanconsulting.com> wrote:
> On Thu, Oct 10, 2013 at 8:35 AM, Gary Gregory <ga...@gmail.com> wrote:
>> I think "milestone" releases works if you have a clear development
>> plan and schedule. I've never seen it be the case in Commons. Calling
>> "releases" to Maven and dist, Alphas and Betas make more sense for us
>> IMO.
>>
>
> I don't care what we call it. They key is that we set up the
> expectation with our users. If you use this release, do NOT use it in
> production code. It is not "supported", meaning we aren't going to
> fix bugs in that alpha version if we have already released its
> subsequent full release version (or a subsequent alpha).
Of course, but naming is important, it communicates intent. With alpha
and beta, you can describe two kinds of releases, with milestone, only
one.
Gary
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
JUnit in Action, Second Edition
Spring Batch in Action
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases [Was:
[DISCUSS] Putting several unmaintained components to dormant]
Posted by James Carman <ja...@carmanconsulting.com>.
On Thu, Oct 10, 2013 at 8:35 AM, Gary Gregory <ga...@gmail.com> wrote:
> I think "milestone" releases works if you have a clear development
> plan and schedule. I've never seen it be the case in Commons. Calling
> "releases" to Maven and dist, Alphas and Betas make more sense for us
> IMO.
>
I don't care what we call it. They key is that we set up the
expectation with our users. If you use this release, do NOT use it in
production code. It is not "supported", meaning we aren't going to
fix bugs in that alpha version if we have already released its
subsequent full release version (or a subsequent alpha).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases [Was:
[DISCUSS] Putting several unmaintained components to dormant]
Posted by Gary Gregory <ga...@gmail.com>.
I think "milestone" releases works if you have a clear development
plan and schedule. I've never seen it be the case in Commons. Calling
"releases" to Maven and dist, Alphas and Betas make more sense for us
IMO.
Gary
On Thu, Oct 10, 2013 at 7:26 AM, Ate Douma <at...@douma.nu> wrote:
> I've move this into a separate [DISCUSS] thread as I think it needs separate
> discussion.
>
> Jörg gave some objections below about using Milestone releases, as I
> proposed earlier to support releasing intermediate versions of a
> not-yet-stabalized component.
>
> While I understand his problems with unstable versions potentially getting
> 'stuck' for long time, where end-users *might* start expecting them to
> remain stable, I don't agree this is, or should be, the common case. Or at
> least not an argument to hold against using such 0.x or -Milestone releases.
>
> Instead, the whole point is to get project/component development moving
> *faster* by allowing *experimental* end-users to provide feedback, and more
> flexibility and convenience for the developers of such project/component.
>
> The idea to have to 'switch' to a next major version for any incompatibile
> change, as Jörg proposes, requiring package changes, whatnot, while a
> project clearly is not ready to stabalize, really puts way too much hurdles
> up for both the developers *and* such experimental end-users, as they would
> HAVE to change all of their code to be able to provide AND leaverage such
> new 0.x or Milestone version.
>
> Case in point: SCXML
> If we are allowed to start working on this component shortly, we intend to,
> and HAVE to switch to a 1.0 version first, as there already is a 0.9 version
> release out, while we will need to move to newer JDK and incompatible API
> changes anyway. At the same time, getting a final/stabalized 1.0 release out
> most certainly will take several iterations.
> I don't want to have to wait doing an intermediate release, nor rapidly
> having to switch to a 2.x/3.x/4.x/etc. versions, just because Milestone
> releases are acceptable for this purpose. Where would Milestone releases [1]
> be useful for otherwise, anyway?
>
> I think a real problem might arise IF other components (or 3rd party
> libraries) would start depending directly on such Milestone releases,
> potentially introducing unexpected instabilities for end-users. And maybe it
> is worthwhile to make such usages, at least for Commons, prohibited. That
> would make sense to me.
>
> But for components like SCXML, javaflow, or csv, this I don't think would be
> a real issue. Those end-users making use of these experimental components
> are, or should be very well aware, of the added responsibility they take
> depending on a not-yet-stabilized version, as clearly is also indicated by
> the version, as well as SHOULD be prominently documented in the release
> notes, readme, etc.
>
> Thoughts?
>
> Ate
>
> On 10/10/2013 12:45 PM, Benedikt Ritter wrote:
>>
>> I like the idea of releasing 0.x versions. A good example is [csv]. I
>> would have no problem with releasing the current trunk as 0.9. At the moment
>> [csv] is just another component we don't releaese because we want to come up
>> with a perfect API (and I take responsibility for that :-)
>>
>> Benedikt
>>
>> Send from my mobile device
>>
>>> Am 10.10.2013 um 12:15 schrieb Jörg Schaible
>>> <Jo...@scalaris.com>:
>>>
>>> Hi,
>>>
>>> Ate Douma wrote:
>>>
>>>>> On 10/10/2013 12:24 AM, Torsten Curdt wrote:
>>>>> Every now and then I keep getting requests via private mail asking to
>>>>> release javaflow as it seems to be working for people. Yet I know there
>>>>> is still so much essential stuff to fix for a 1.0 release.
>>>>>
>>>>> Crossing over to the other thread: I know on github I would made a 0.x
>>>>> release already ages ago but knowing I won't have time to work on it
>>>>> anymore I keep pushing this out at commons.
>>>>
>>>>
>>>> Wouldn't this be a case to allow and use intermediate milestone
>>>> releases?
>>>>
>>>> Using a 1.0-Mxx version would make still clear to the users things
>>>> haven't
>>>> settled yet (API wise), so should not limit or restrict making API
>>>> changes
>>>> before a final 1.0 release, but would help both the community and the
>>>> project moving. More likely to incite further involvement and
>>>> contributions, etc.
>>>>
>>>> Being 'stuck' on getting a (final) 1.0 release out because everything
>>>> should be settled and 'frozen' (API wise) first doesn't make sense to me
>>>> at all.
>>>
>>>
>>> We should not be so afraid to switch to 2.x if the 1.x API turns out to
>>> be
>>> cumbersome in some cases. Typically you may also increase Java level in
>>> the
>>> meantime and therefore eventually even have a benefit of new
>>> possibilities.
>>>
>>>> "Release early and often" really is what keeps open source projects
>>>> moving
>>>> forward, *any* policy which blocks that is plain wrong and should be
>>>> fixed.
>>>>
>>>> Note: I'm not saying I'm against the strict versioning rules, but those
>>>> should NOT block getting to a 1.0 release easily.
>>>> And I don't think they do. Isn't this where Milestone releases are meant
>>>> for?
>>>
>>>
>>> I am not a big fan of milestones unless we really have a forced schedule
>>> for
>>> the final release. If we get into the situation that the milestone is the
>>> latest release for months, we get into jar hell again, because that
>>> milestone is then *used* like any proper release. You cannot prevent
>>> this.
>>>
>>> There is a reason why I have to use for a (private) Maven plugin an
>>> artifact
>>> like
>>> org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9-stable-1.
>>> That's a result of such a "milestone" and I really like to avoid this
>>> situation for Apache Commons.
>>>
>>>>> Release and put into dormant?
>>>>> It's a strange situation.
>>>
>>>
>>> No release it as 1.0 and go on with 2.x, since 1.0 is probably already
>>> based
>>> on old technology.
>>>
>>> - Jörg
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
JUnit in Action, Second Edition
Spring Batch in Action
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases
Posted by James Carman <ja...@carmanconsulting.com>.
Rookie ;). You had me at "faster"! :)
On Thursday, October 10, 2013, Ate Douma wrote:
> Sigh, typical mistake of forgetting to provide the link referenced further
> below:
>
> [1] http://commons.apache.org/**releases/versioning.html#**
> Milestone_Releases<http://commons.apache.org/releases/versioning.html#Milestone_Releases>
>
> On 10/10/2013 01:26 PM, Ate Douma wrote:
>
>> I've move this into a separate [DISCUSS] thread as I think it needs
>> separate
>> discussion.
>>
>> Jörg gave some objections below about using Milestone releases, as I
>> proposed
>> earlier to support releasing intermediate versions of a not-yet-stabalized
>> component.
>>
>> While I understand his problems with unstable versions potentially getting
>> 'stuck' for long time, where end-users *might* start expecting them to
>> remain
>> stable, I don't agree this is, or should be, the common case. Or at least
>> not an
>> argument to hold against using such 0.x or -Milestone releases.
>>
>> Instead, the whole point is to get project/component development moving
>> *faster*
>> by allowing *experimental* end-users to provide feedback, and more
>> flexibility
>> and convenience for the developers of such project/component.
>>
>> The idea to have to 'switch' to a next major version for any incompatibile
>> change, as Jörg proposes, requiring package changes, whatnot, while a
>> project
>> clearly is not ready to stabalize, really puts way too much hurdles up
>> for both
>> the developers *and* such experimental end-users, as they would HAVE to
>> change
>> all of their code to be able to provide AND leaverage such new 0.x or
>> Milestone
>> version.
>>
>> Case in point: SCXML
>> If we are allowed to start working on this component shortly, we intend
>> to, and
>> HAVE to switch to a 1.0 version first, as there already is a 0.9 version
>> release
>> out, while we will need to move to newer JDK and incompatible API changes
>> anyway. At the same time, getting a final/stabalized 1.0 release out most
>> certainly will take several iterations.
>> I don't want to have to wait doing an intermediate release, nor rapidly
>> having
>> to switch to a 2.x/3.x/4.x/etc. versions, just because Milestone releases
>> are
>> acceptable for this purpose.
>>
> Of course I inteded to say 'just because Milestone releases are NOT
> acceptable for this purpose'.
>
> Where would Milestone releases [1] be useful for
>> otherwise, anyway?
>>
>> I think a real problem might arise IF other components (or 3rd party
>> libraries)
>> would start depending directly on such Milestone releases, potentially
>> introducing unexpected instabilities for end-users. And maybe it is
>> worthwhile
>> to make such usages, at least for Commons, prohibited. That would make
>> sense to me.
>>
>> But for components like SCXML, javaflow, or csv, this I don't think would
>> be a
>> real issue. Those end-users making use of these experimental components
>> are, or
>> should be very well aware, of the added responsibility they take
>> depending on a
>> not-yet-stabilized version, as clearly is also indicated by the version,
>> as well
>> as SHOULD be prominently documented in the release notes, readme, etc.
>>
>> Thoughts?
>>
>> Ate
>>
>> On 10/10/2013 12:45 PM, Benedikt Ritter wrote:
>>
>>> I like the idea of releasing 0.x versions. A good example is [csv]. I
>>> would
>>> have no problem with releasing the current trunk as 0.9. At the moment
>>> [csv]
>>> is just another component we don't releaese because we want to come up
>>> with a
>>> perfect API (and I take responsibility for that :-)
>>>
>>> Benedikt
>>>
>>> Send from my mobile device
>>>
>>> Am 10.10.2013 um 12:15 schrieb Jörg Schaible <
>>>> Joerg.Schaible@scalaris.com>:
>>>>
>>>> Hi,
>>>>
>>>> Ate Douma wrote:
>>>>
>>>> On 10/10/2013 12:24 AM, Torsten Curdt wrote:
>>>>>> Every now and then I keep getting requests via private mail asking to
>>>>>> release javaflow as it seems to be working for people. Yet I know
>>>>>> there
>>>>>> is still so much essential stuff to fix for a 1.0 release.
>>>>>>
>>>>>> Crossing over to the other thread: I know on github I would made a 0.x
>>>>>> release already ages ago but knowing I won't have time to work on it
>>>>>> anymore I keep pushing this out at commons.
>>>>>>
>>>>>
>>>>> Wouldn't this be a case to allow and use intermediate milestone
>>>>> releases?
>>>>>
>>>>> Using a 1.0-Mxx version would make still clear to the users things
>>>>> haven't
>>>>> settled yet (API wise), so should not limit or restrict making API
>>>>> changes
>>>>> before a final 1.0 release, but would help both the community and the
>>>>> project moving. More likely to incite further involvement and
>>>>> contributions, etc.
>>>>>
>>>>> Being 'stuck' on getting a (final) 1.0 release out because everything
>>>>> should be settled and 'frozen' (API wise) first doesn't make sense to
>>>>> me
>>>>> at all.
>>>>>
>>>>
>>>> We should not be so afraid to switch to 2.x if the 1.x API turns out to
>>>> be
>>>> cumbersome in some cases. Typically you may also increase Java level in
>>>> the
>>>> meantime and therefore eventually even have a benefit of new
>>>> possibilities.
>>>>
>>>> "Release early and often" really is what keeps open source projects
>>>>> moving
>>>>> forward, *any* policy which blocks that is plain wrong and should be
>>>>> fixed.
>>>>>
>>>>> Note: I'm not saying I'm against the strict versioning rules, but those
>>>>> should NOT block getting to a 1.0 release easily.
>>>>> And I don't think they do. Isn't this where Milestone releases are
>>>>> meant
>>>>> for?
>>>>>
>>>>
>>>> I am not a big fan of milestones unless we really have a forced
>>>> schedule for
>>>> the final release. If we get into the situation that the milestone is
>>>> the
>>>> latest release for months, we get into jar hell again, because that
>>>> milestone is then *used* like any proper release. You cannot prevent
>>>> this.
>>>>
>>>> There is a reason why I have to use for a (private) Maven plugin an
>>>> artifact
>>>> like org.codehaus.plexus:plexus-**container-default:jar:1.0-**
>>>> alpha-9-stable-1.
>>>> That's a result of such a "milestone" and I really like to avoid this
>>>> situation for Apache Commons.
>>>>
>>>> Release and put into dormant?
>>>>>> It's a strange situation.
>>>>>>
>>>>>
>>>> No release it as 1.0 and go on with 2.x, since 1.0 is probably already
>>>> based
>>>> on old technology.
>>>>
>>>> - Jörg
>>>>
>>>>
>>>> ------------------------------**------------------------------**
>>>> ---------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>> ------------------------------**------------------------------**
>>> ---------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>>
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases
Posted by Ate Douma <at...@douma.nu>.
Sigh, typical mistake of forgetting to provide the link referenced further below:
[1] http://commons.apache.org/releases/versioning.html#Milestone_Releases
On 10/10/2013 01:26 PM, Ate Douma wrote:
> I've move this into a separate [DISCUSS] thread as I think it needs separate
> discussion.
>
> Jörg gave some objections below about using Milestone releases, as I proposed
> earlier to support releasing intermediate versions of a not-yet-stabalized
> component.
>
> While I understand his problems with unstable versions potentially getting
> 'stuck' for long time, where end-users *might* start expecting them to remain
> stable, I don't agree this is, or should be, the common case. Or at least not an
> argument to hold against using such 0.x or -Milestone releases.
>
> Instead, the whole point is to get project/component development moving *faster*
> by allowing *experimental* end-users to provide feedback, and more flexibility
> and convenience for the developers of such project/component.
>
> The idea to have to 'switch' to a next major version for any incompatibile
> change, as Jörg proposes, requiring package changes, whatnot, while a project
> clearly is not ready to stabalize, really puts way too much hurdles up for both
> the developers *and* such experimental end-users, as they would HAVE to change
> all of their code to be able to provide AND leaverage such new 0.x or Milestone
> version.
>
> Case in point: SCXML
> If we are allowed to start working on this component shortly, we intend to, and
> HAVE to switch to a 1.0 version first, as there already is a 0.9 version release
> out, while we will need to move to newer JDK and incompatible API changes
> anyway. At the same time, getting a final/stabalized 1.0 release out most
> certainly will take several iterations.
> I don't want to have to wait doing an intermediate release, nor rapidly having
> to switch to a 2.x/3.x/4.x/etc. versions, just because Milestone releases are
> acceptable for this purpose.
Of course I inteded to say 'just because Milestone releases are NOT acceptable
for this purpose'.
> Where would Milestone releases [1] be useful for
> otherwise, anyway?
>
> I think a real problem might arise IF other components (or 3rd party libraries)
> would start depending directly on such Milestone releases, potentially
> introducing unexpected instabilities for end-users. And maybe it is worthwhile
> to make such usages, at least for Commons, prohibited. That would make sense to me.
>
> But for components like SCXML, javaflow, or csv, this I don't think would be a
> real issue. Those end-users making use of these experimental components are, or
> should be very well aware, of the added responsibility they take depending on a
> not-yet-stabilized version, as clearly is also indicated by the version, as well
> as SHOULD be prominently documented in the release notes, readme, etc.
>
> Thoughts?
>
> Ate
>
> On 10/10/2013 12:45 PM, Benedikt Ritter wrote:
>> I like the idea of releasing 0.x versions. A good example is [csv]. I would
>> have no problem with releasing the current trunk as 0.9. At the moment [csv]
>> is just another component we don't releaese because we want to come up with a
>> perfect API (and I take responsibility for that :-)
>>
>> Benedikt
>>
>> Send from my mobile device
>>
>>> Am 10.10.2013 um 12:15 schrieb Jörg Schaible <Jo...@scalaris.com>:
>>>
>>> Hi,
>>>
>>> Ate Douma wrote:
>>>
>>>>> On 10/10/2013 12:24 AM, Torsten Curdt wrote:
>>>>> Every now and then I keep getting requests via private mail asking to
>>>>> release javaflow as it seems to be working for people. Yet I know there
>>>>> is still so much essential stuff to fix for a 1.0 release.
>>>>>
>>>>> Crossing over to the other thread: I know on github I would made a 0.x
>>>>> release already ages ago but knowing I won't have time to work on it
>>>>> anymore I keep pushing this out at commons.
>>>>
>>>> Wouldn't this be a case to allow and use intermediate milestone releases?
>>>>
>>>> Using a 1.0-Mxx version would make still clear to the users things haven't
>>>> settled yet (API wise), so should not limit or restrict making API changes
>>>> before a final 1.0 release, but would help both the community and the
>>>> project moving. More likely to incite further involvement and
>>>> contributions, etc.
>>>>
>>>> Being 'stuck' on getting a (final) 1.0 release out because everything
>>>> should be settled and 'frozen' (API wise) first doesn't make sense to me
>>>> at all.
>>>
>>> We should not be so afraid to switch to 2.x if the 1.x API turns out to be
>>> cumbersome in some cases. Typically you may also increase Java level in the
>>> meantime and therefore eventually even have a benefit of new possibilities.
>>>
>>>> "Release early and often" really is what keeps open source projects moving
>>>> forward, *any* policy which blocks that is plain wrong and should be
>>>> fixed.
>>>>
>>>> Note: I'm not saying I'm against the strict versioning rules, but those
>>>> should NOT block getting to a 1.0 release easily.
>>>> And I don't think they do. Isn't this where Milestone releases are meant
>>>> for?
>>>
>>> I am not a big fan of milestones unless we really have a forced schedule for
>>> the final release. If we get into the situation that the milestone is the
>>> latest release for months, we get into jar hell again, because that
>>> milestone is then *used* like any proper release. You cannot prevent this.
>>>
>>> There is a reason why I have to use for a (private) Maven plugin an artifact
>>> like org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9-stable-1.
>>> That's a result of such a "milestone" and I really like to avoid this
>>> situation for Apache Commons.
>>>
>>>>> Release and put into dormant?
>>>>> It's a strange situation.
>>>
>>> No release it as 1.0 and go on with 2.x, since 1.0 is probably already based
>>> on old technology.
>>>
>>> - Jörg
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases [Was:
[DISCUSS] Putting several unmaintained components to dormant]
Posted by James Carman <ja...@carmanconsulting.com>.
I'm okay with alpha/milestone/rc/whatever. Do we promote them to central
or leave them local? Keeping them in-house might help keep folks from
incorporating them into production code. However I'm okay with publishing
too. Hibernate has done this for years (rc's).
On Thursday, October 10, 2013, Ate Douma wrote:
> I've move this into a separate [DISCUSS] thread as I think it needs
> separate discussion.
>
> Jörg gave some objections below about using Milestone releases, as I
> proposed earlier to support releasing intermediate versions of a
> not-yet-stabalized component.
>
> While I understand his problems with unstable versions potentially getting
> 'stuck' for long time, where end-users *might* start expecting them to
> remain stable, I don't agree this is, or should be, the common case. Or at
> least not an argument to hold against using such 0.x or -Milestone releases.
>
> Instead, the whole point is to get project/component development moving
> *faster* by allowing *experimental* end-users to provide feedback, and more
> flexibility and convenience for the developers of such project/component.
>
> The idea to have to 'switch' to a next major version for any incompatibile
> change, as Jörg proposes, requiring package changes, whatnot, while a
> project clearly is not ready to stabalize, really puts way too much hurdles
> up for both the developers *and* such experimental end-users, as they would
> HAVE to change all of their code to be able to provide AND leaverage such
> new 0.x or Milestone version.
>
> Case in point: SCXML
> If we are allowed to start working on this component shortly, we intend
> to, and HAVE to switch to a 1.0 version first, as there already is a 0.9
> version release out, while we will need to move to newer JDK and
> incompatible API changes anyway. At the same time, getting a
> final/stabalized 1.0 release out most certainly will take several
> iterations.
> I don't want to have to wait doing an intermediate release, nor rapidly
> having to switch to a 2.x/3.x/4.x/etc. versions, just because Milestone
> releases are acceptable for this purpose. Where would Milestone releases
> [1] be useful for otherwise, anyway?
>
> I think a real problem might arise IF other components (or 3rd party
> libraries) would start depending directly on such Milestone releases,
> potentially introducing unexpected instabilities for end-users. And maybe
> it is worthwhile to make such usages, at least for Commons, prohibited.
> That would make sense to me.
>
> But for components like SCXML, javaflow, or csv, this I don't think would
> be a real issue. Those end-users making use of these experimental
> components are, or should be very well aware, of the added responsibility
> they take depending on a not-yet-stabilized version, as clearly is also
> indicated by the version, as well as SHOULD be prominently documented in
> the release notes, readme, etc.
>
> Thoughts?
>
> Ate
>
> On 10/10/2013 12:45 PM, Benedikt Ritter wrote:
>
>> I like the idea of releasing 0.x versions. A good example is [csv]. I
>> would have no problem with releasing the current trunk as 0.9. At the
>> moment [csv] is just another component we don't releaese because we want to
>> come up with a perfect API (and I take responsibility for that :-)
>>
>> Benedikt
>>
>> Send from my mobile device
>>
>> Am 10.10.2013 um 12:15 schrieb Jörg Schaible <
>>> Joerg.Schaible@scalaris.com>:
>>>
>>> Hi,
>>>
>>> Ate Douma wrote:
>>>
>>> On 10/10/2013 12:24 AM, Torsten Curdt wrote:
>>>>> Every now and then I keep getting requests via private mail asking to
>>>>> release javaflow as it seems to be working for people. Yet I know there
>>>>> is still so much essential stuff to fix for a 1.0 release.
>>>>>
>>>>> Crossing over to the other thread: I know on github I would made a 0.x
>>>>> release already ages ago but knowing I won't have time to work on it
>>>>> anymore I keep pushing this out at commons.
>>>>>
>>>>
>>>> Wouldn't this be a case to allow and use intermediate milestone
>>>> releases?
>>>>
>>>> Using a 1.0-Mxx version would make still clear to the users things
>>>> haven't
>>>> settled yet (API wise), so should not limit or restrict making API
>>>> changes
>>>> before a final 1.0 release, but would help both the community and the
>>>> project moving. More likely to incite further involvement and
>>>> contributions, etc.
>>>>
>>>> Being 'stuck' on getting a (final) 1.0 release out because everything
>>>> should be settled and 'frozen' (API wise) first doesn't make sense to me
>>>> at all.
>>>>
>>>
>>> We should not be so afraid to switch to 2.x if the 1.x API turns out to
>>> be
>>> cumbersome in some cases. Typically you may also increase Java level in
>>> the
>>> meantime and therefore eventually even have a benefit of new
>>> possibilities.
>>>
>>> "Release early and often" really is what keeps open source projects
>>>> moving
>>>> forward, *any* policy which blocks that is plain wrong and should be
>>>> fixed.
>>>>
>>>> Note: I'm not saying I'm against the strict versioning rules, but those
>>>> should NOT block getting to a 1.0 release easily.
>>>> And I don't think they do. Isn't this where Milestone releases are meant
>>>> for?
>>>>
>>>
>>> I am not a big fan of milestones unless we really have a forced schedule
>>> for
>>> the final release. If we get into the situation that the milestone is the
>>> latest release for months, we get into jar hell again, because that
>>> milestone is then *used* like any proper release. You cannot prevent
>>> this.
>>>
>>> There is a reason why I have to use for a (private) Maven plugin an
>>> artifact
>>> like org.codehaus.plexus:plexus-**container-default:jar:1.0-**
>>> alpha-9-stable-1.
>>> That's a result of such a "milestone" and I really like to avoid this
>>> situation for Apache Commons.
>>>
>>> Release and put into dormant?
>>>>> It's a strange situation.
>>>>>
>>>>
>>> No release it as 1.0 and go on with 2.x, since 1.0 is probably already
>>> based
>>> on old technology.
>>>
>>> - Jörg
>>>
>>>
>>> ------------------------------**------------------------------**
>>> ---------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases
Posted by Benedikt Ritter <be...@gmail.com>.
Send from my mobile device
> Am 10.10.2013 um 14:44 schrieb Gary Gregory <ga...@gmail.com>:
>
>> On Thu, Oct 10, 2013 at 7:36 AM, Emmanuel Bourg <eb...@apache.org> wrote:
>> Le 10/10/2013 13:26, Ate Douma a écrit :
>>
>>> Thoughts?
>>
>> A solution could be to change the package for every preview release.
>> Something like:
>>
>> org.apache.commons.experimental.<componentname><number>
>>
>> So, for CSV we could release a 0.8 and 0.9 version under the packages:
>>
>> org.apache.commons.experimental.csv8
>> org.apache.commons.experimental.csv9
>>
>> The package translation could probably be automated by the shade plugin,
>> such that we keep developing with the org.apache.commons.csv package.
>>
>> Emmanuel Bourg
>
> I call this "Extreme Versioning", and I've thought about it in the
> past. Each release lives in it's own package, major, minor,
> maintenance. As a developer, this leads you to make a conscious choice
> as to when to pick up a bug fix or new feature from a new version of a
> jar, you have to act. This is different than just new dropping jars
> into your classpath (or POM) and hoping for the best. It also
> guarantees binary compatibility, BC becomes a non-issue. It is an
> extreme POV to be sure. If I want to create an "unsupported" jar
> combo, I have to shade jars and change package names.
I feel we've nearly arrived in OSGi land ;-)
>
> Gary
>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> JUnit in Action, Second Edition
> Spring Batch in Action
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases
Posted by Gary Gregory <ga...@gmail.com>.
On Thu, Oct 10, 2013 at 7:36 AM, Emmanuel Bourg <eb...@apache.org> wrote:
> Le 10/10/2013 13:26, Ate Douma a écrit :
>
>> Thoughts?
>
> A solution could be to change the package for every preview release.
> Something like:
>
> org.apache.commons.experimental.<componentname><number>
>
> So, for CSV we could release a 0.8 and 0.9 version under the packages:
>
> org.apache.commons.experimental.csv8
> org.apache.commons.experimental.csv9
>
> The package translation could probably be automated by the shade plugin,
> such that we keep developing with the org.apache.commons.csv package.
>
> Emmanuel Bourg
I call this "Extreme Versioning", and I've thought about it in the
past. Each release lives in it's own package, major, minor,
maintenance. As a developer, this leads you to make a conscious choice
as to when to pick up a bug fix or new feature from a new version of a
jar, you have to act. This is different than just new dropping jars
into your classpath (or POM) and hoping for the best. It also
guarantees binary compatibility, BC becomes a non-issue. It is an
extreme POV to be sure. If I want to create an "unsupported" jar
combo, I have to shade jars and change package names.
Gary
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
JUnit in Action, Second Edition
Spring Batch in Action
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases
Posted by James Carman <ja...@carmanconsulting.com>.
Agreed. Keep it simple.
On Thursday, October 10, 2013, Ate Douma wrote:
> On 10/10/2013 01:36 PM, Emmanuel Bourg wrote:
>
>> Le 10/10/2013 13:26, Ate Douma a écrit :
>>
>> Thoughts?
>>>
>>
>> A solution could be to change the package for every preview release.
>> Something like:
>>
>> org.apache.commons.**experimental.<componentname><**number>
>>
>> So, for CSV we could release a 0.8 and 0.9 version under the packages:
>>
>> org.apache.commons.**experimental.csv8
>> org.apache.commons.**experimental.csv9
>>
>> The package translation could probably be automated by the shade plugin,
>> such that we keep developing with the org.apache.commons.csv package.
>>
>
> While doing this might be somewhat automated, sure, I still would not
> favor this.
> I think it tries to solve more of a perceived than an actual problem.
> And it is not convenient for the experimental end-users either, because
> they most definitely will HAVE to modify their code (manually).
>
>
>> Emmanuel Bourg
>>
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases
Posted by Ate Douma <at...@douma.nu>.
On 10/10/2013 03:06 PM, James Carman wrote:
> On Thu, Oct 10, 2013 at 8:25 AM, Emmanuel Bourg <eb...@apache.org> wrote:
>>
>> I'm afraid this is more than a perceived issue, the plexus-container
>> example given by Jörg is a very good one. Pushing drastically
>> incompatible versions to Maven Central is not a good service for the users.
>>
>> I think my suggestion is a good compromise, otherwise the die-hard
>> compatibility defenders here will never agree to publish incompatible
>> artifacts to Maven Central.
>>
>
> This gets back to my earlier comments on another thread. We can't try
> to stupid-proof our code. If our users want to do something stupid,
> we can't protect them from themselves. If they want to "release" code
> which points to milestone/alpha/rc/SNAPSHOT/whatever, then that's on
> them.
>
>>
>> I agree this is annoying, but this has to be balanced with the annoyance
>> of dealing with incompatible dependencies (for example, components
>> depending on different versions of BouncyCastle). It's easy to rename an
>> import in your code compared to fixing a jar hell situation.
>>
>
> If a third-party library releases a version which points at one of our
> alpha releases and relies upon an API that they've been told may not
> be stable, then they need to fix it. Again, we can boil the ocean
> trying to think up all the stupid things people can do with our
> software and try to code/process around it, but at the end of the day,
> you can't fix stupid.
Amen to that
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases
Posted by Ate Douma <at...@douma.nu>.
On 10/10/2013 04:06 PM, Gary Gregory wrote:
> On Thu, Oct 10, 2013 at 9:55 AM, Ate Douma <at...@douma.nu> wrote:
>> On 10/10/2013 03:47 PM, Gary Gregory wrote:
>>>
>>> On Thu, Oct 10, 2013 at 9:06 AM, James Carman
>>> <ja...@carmanconsulting.com> wrote:
>>>>
>>>> On Thu, Oct 10, 2013 at 8:25 AM, Emmanuel Bourg <eb...@apache.org>
>>>> wrote:
>>>>>
>>>>>
>>>>> I'm afraid this is more than a perceived issue, the plexus-container
>>>>> example given by Jörg is a very good one. Pushing drastically
>>>>> incompatible versions to Maven Central is not a good service for the
>>>>> users.
>>>>>
>>>>> I think my suggestion is a good compromise, otherwise the die-hard
>>>>> compatibility defenders here will never agree to publish incompatible
>>>>> artifacts to Maven Central.
>>>>>
>>>>
>>>> This gets back to my earlier comments on another thread. We can't try
>>>> to stupid-proof our code. If our users want to do something stupid,
>>>> we can't protect them from themselves. If they want to "release" code
>>>> which points to milestone/alpha/rc/SNAPSHOT/whatever, then that's on
>>>> them.
>>>>
>>>>>
>>>>> I agree this is annoying, but this has to be balanced with the annoyance
>>>>> of dealing with incompatible dependencies (for example, components
>>>>> depending on different versions of BouncyCastle). It's easy to rename an
>>>>> import in your code compared to fixing a jar hell situation.
>>>>>
>>>>
>>>> If a third-party library releases a version which points at one of our
>>>> alpha releases and relies upon an API that they've been told may not
>>>> be stable, then they need to fix it. Again, we can boil the ocean
>>>> trying to think up all the stupid things people can do with our
>>>> software and try to code/process around it, but at the end of the day,
>>>> you can't fix stupid.
>>>
>>>
>>> Indeed, developers and users will forever find creative and painful
>>> ways to shoot themselves in the foot and other appendages.
>>>
>>> Conversely, we should not hand out defective weaponry by breaking
>>> Binary Compatibility (this relates to a discussion on another thread:
>>> I claim it is never OK to break BC, you release a new (Java) package
>>> to do the equivalent).
>>
>>
>> I state that an alpha release (which I gather you prefer above calling it
>> milestones), by definition, cannot have a 'Compatibility' claim to begin
>> with, hence cannot break one either.
>>
>> So, are you OK with alpha releases, which do NOT claim any stability nor
>> compatibility?
>
> Yes, an alpha is an anything goes release.
Thanks, that's all I needed to hear :)
>
> Whether or not it is in a special package is a different story :)
But because it is an 'anything goes release', it doesn't really matter, is up to
the developer(s), and at any rate CANNOT be a restriction on a release.
Ate
>
> Gary
>
>>
>>
>>>
>>> Gary
>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>
>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases
Posted by Ate Douma <at...@douma.nu>.
On 10/10/2013 04:31 PM, James Carman wrote:
> On Thu, Oct 10, 2013 at 10:19 AM, Ate Douma <at...@douma.nu> wrote:
>>
>> I'm a bit unfamiliar yet with the 'rules' within Commons concerning such
>> changes. I'm willing to create an issue for this and draft up a
>> documentation patch for it, but maybe this needs formal voting by the PMC
>> first?
>>
>
> I'd suggest a vote. This way we have documentation that a decision
> was made to move in this direction and we don't have to re-hash the
> discussion every time someone wants to do an alpha release or break BC
> between alpha releases. We should probably vote before establishing
> such "policy" changes. This doesn't mean components *have* to do
> alphas if they don't want, but we're merely establishing that it's an
> acceptable practice within Commons to do so and more importantly to
> establish the expectations when the situation arises.
>
Great!
If OK, I'm willing to draft up a proposal for such a VOTE, with text ready to be
incorporated in the Versioning documentation once accepted.
Ate
> Hopefully once we get our release process streamlined we can do these
> releases much more frequently and get our cool code in our users'
> hands quickly!
>
> Great discussions, folks. I'm glad to see us thinking like this.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases
Posted by James Carman <ja...@carmanconsulting.com>.
On Thu, Oct 10, 2013 at 10:19 AM, Ate Douma <at...@douma.nu> wrote:
>
> I'm a bit unfamiliar yet with the 'rules' within Commons concerning such
> changes. I'm willing to create an issue for this and draft up a
> documentation patch for it, but maybe this needs formal voting by the PMC
> first?
>
I'd suggest a vote. This way we have documentation that a decision
was made to move in this direction and we don't have to re-hash the
discussion every time someone wants to do an alpha release or break BC
between alpha releases. We should probably vote before establishing
such "policy" changes. This doesn't mean components *have* to do
alphas if they don't want, but we're merely establishing that it's an
acceptable practice within Commons to do so and more importantly to
establish the expectations when the situation arises.
Hopefully once we get our release process streamlined we can do these
releases much more frequently and get our cool code in our users'
hands quickly!
Great discussions, folks. I'm glad to see us thinking like this.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases
Posted by Ate Douma <at...@douma.nu>.
On 10/10/2013 04:13 PM, James Carman wrote:
> Well, alphas still shouldn't break backward compatibility with a prior
> *full* release within a major version number. If they do, then it's a
> bug we need to address it. So, it's not really "anything goes." At
> least, that's how I'd think about it. Any new APIs are considered
> "volatile" and subject to change before the next full release.
Yes, that is a good refinement. "Anything goes" indeed isn't needed nor asked for.
So... as we seem to get to an understanding here with respect to the meaning and
usage of 'alpha' releases, how about adding this to the Versioning
documentation? Currently there is wording for milestones, but not yet alpha
releases.
I'm a bit unfamiliar yet with the 'rules' within Commons concerning such
changes. I'm willing to create an issue for this and draft up a documentation
patch for it, but maybe this needs formal voting by the PMC first?
Thanks, Ate
>
> On Thu, Oct 10, 2013 at 10:06 AM, Gary Gregory <ga...@gmail.com> wrote:
>> On Thu, Oct 10, 2013 at 9:55 AM, Ate Douma <at...@douma.nu> wrote:
>>> On 10/10/2013 03:47 PM, Gary Gregory wrote:
>>>>
>>>> On Thu, Oct 10, 2013 at 9:06 AM, James Carman
>>>> <ja...@carmanconsulting.com> wrote:
>>>>>
>>>>> On Thu, Oct 10, 2013 at 8:25 AM, Emmanuel Bourg <eb...@apache.org>
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> I'm afraid this is more than a perceived issue, the plexus-container
>>>>>> example given by Jörg is a very good one. Pushing drastically
>>>>>> incompatible versions to Maven Central is not a good service for the
>>>>>> users.
>>>>>>
>>>>>> I think my suggestion is a good compromise, otherwise the die-hard
>>>>>> compatibility defenders here will never agree to publish incompatible
>>>>>> artifacts to Maven Central.
>>>>>>
>>>>>
>>>>> This gets back to my earlier comments on another thread. We can't try
>>>>> to stupid-proof our code. If our users want to do something stupid,
>>>>> we can't protect them from themselves. If they want to "release" code
>>>>> which points to milestone/alpha/rc/SNAPSHOT/whatever, then that's on
>>>>> them.
>>>>>
>>>>>>
>>>>>> I agree this is annoying, but this has to be balanced with the annoyance
>>>>>> of dealing with incompatible dependencies (for example, components
>>>>>> depending on different versions of BouncyCastle). It's easy to rename an
>>>>>> import in your code compared to fixing a jar hell situation.
>>>>>>
>>>>>
>>>>> If a third-party library releases a version which points at one of our
>>>>> alpha releases and relies upon an API that they've been told may not
>>>>> be stable, then they need to fix it. Again, we can boil the ocean
>>>>> trying to think up all the stupid things people can do with our
>>>>> software and try to code/process around it, but at the end of the day,
>>>>> you can't fix stupid.
>>>>
>>>>
>>>> Indeed, developers and users will forever find creative and painful
>>>> ways to shoot themselves in the foot and other appendages.
>>>>
>>>> Conversely, we should not hand out defective weaponry by breaking
>>>> Binary Compatibility (this relates to a discussion on another thread:
>>>> I claim it is never OK to break BC, you release a new (Java) package
>>>> to do the equivalent).
>>>
>>>
>>> I state that an alpha release (which I gather you prefer above calling it
>>> milestones), by definition, cannot have a 'Compatibility' claim to begin
>>> with, hence cannot break one either.
>>>
>>> So, are you OK with alpha releases, which do NOT claim any stability nor
>>> compatibility?
>>
>> Yes, an alpha is an anything goes release.
>>
>> Whether or not it is in a special package is a different story :)
>>
>> Gary
>>
>>>
>>>
>>>>
>>>> Gary
>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> Java Persistence with Hibernate, Second Edition
>> JUnit in Action, Second Edition
>> Spring Batch in Action
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases
Posted by James Carman <ja...@carmanconsulting.com>.
Well, alphas still shouldn't break backward compatibility with a prior
*full* release within a major version number. If they do, then it's a
bug we need to address it. So, it's not really "anything goes." At
least, that's how I'd think about it. Any new APIs are considered
"volatile" and subject to change before the next full release.
On Thu, Oct 10, 2013 at 10:06 AM, Gary Gregory <ga...@gmail.com> wrote:
> On Thu, Oct 10, 2013 at 9:55 AM, Ate Douma <at...@douma.nu> wrote:
>> On 10/10/2013 03:47 PM, Gary Gregory wrote:
>>>
>>> On Thu, Oct 10, 2013 at 9:06 AM, James Carman
>>> <ja...@carmanconsulting.com> wrote:
>>>>
>>>> On Thu, Oct 10, 2013 at 8:25 AM, Emmanuel Bourg <eb...@apache.org>
>>>> wrote:
>>>>>
>>>>>
>>>>> I'm afraid this is more than a perceived issue, the plexus-container
>>>>> example given by Jörg is a very good one. Pushing drastically
>>>>> incompatible versions to Maven Central is not a good service for the
>>>>> users.
>>>>>
>>>>> I think my suggestion is a good compromise, otherwise the die-hard
>>>>> compatibility defenders here will never agree to publish incompatible
>>>>> artifacts to Maven Central.
>>>>>
>>>>
>>>> This gets back to my earlier comments on another thread. We can't try
>>>> to stupid-proof our code. If our users want to do something stupid,
>>>> we can't protect them from themselves. If they want to "release" code
>>>> which points to milestone/alpha/rc/SNAPSHOT/whatever, then that's on
>>>> them.
>>>>
>>>>>
>>>>> I agree this is annoying, but this has to be balanced with the annoyance
>>>>> of dealing with incompatible dependencies (for example, components
>>>>> depending on different versions of BouncyCastle). It's easy to rename an
>>>>> import in your code compared to fixing a jar hell situation.
>>>>>
>>>>
>>>> If a third-party library releases a version which points at one of our
>>>> alpha releases and relies upon an API that they've been told may not
>>>> be stable, then they need to fix it. Again, we can boil the ocean
>>>> trying to think up all the stupid things people can do with our
>>>> software and try to code/process around it, but at the end of the day,
>>>> you can't fix stupid.
>>>
>>>
>>> Indeed, developers and users will forever find creative and painful
>>> ways to shoot themselves in the foot and other appendages.
>>>
>>> Conversely, we should not hand out defective weaponry by breaking
>>> Binary Compatibility (this relates to a discussion on another thread:
>>> I claim it is never OK to break BC, you release a new (Java) package
>>> to do the equivalent).
>>
>>
>> I state that an alpha release (which I gather you prefer above calling it
>> milestones), by definition, cannot have a 'Compatibility' claim to begin
>> with, hence cannot break one either.
>>
>> So, are you OK with alpha releases, which do NOT claim any stability nor
>> compatibility?
>
> Yes, an alpha is an anything goes release.
>
> Whether or not it is in a special package is a different story :)
>
> Gary
>
>>
>>
>>>
>>> Gary
>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>
>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> JUnit in Action, Second Edition
> Spring Batch in Action
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases
Posted by Gary Gregory <ga...@gmail.com>.
On Thu, Oct 10, 2013 at 9:55 AM, Ate Douma <at...@douma.nu> wrote:
> On 10/10/2013 03:47 PM, Gary Gregory wrote:
>>
>> On Thu, Oct 10, 2013 at 9:06 AM, James Carman
>> <ja...@carmanconsulting.com> wrote:
>>>
>>> On Thu, Oct 10, 2013 at 8:25 AM, Emmanuel Bourg <eb...@apache.org>
>>> wrote:
>>>>
>>>>
>>>> I'm afraid this is more than a perceived issue, the plexus-container
>>>> example given by Jörg is a very good one. Pushing drastically
>>>> incompatible versions to Maven Central is not a good service for the
>>>> users.
>>>>
>>>> I think my suggestion is a good compromise, otherwise the die-hard
>>>> compatibility defenders here will never agree to publish incompatible
>>>> artifacts to Maven Central.
>>>>
>>>
>>> This gets back to my earlier comments on another thread. We can't try
>>> to stupid-proof our code. If our users want to do something stupid,
>>> we can't protect them from themselves. If they want to "release" code
>>> which points to milestone/alpha/rc/SNAPSHOT/whatever, then that's on
>>> them.
>>>
>>>>
>>>> I agree this is annoying, but this has to be balanced with the annoyance
>>>> of dealing with incompatible dependencies (for example, components
>>>> depending on different versions of BouncyCastle). It's easy to rename an
>>>> import in your code compared to fixing a jar hell situation.
>>>>
>>>
>>> If a third-party library releases a version which points at one of our
>>> alpha releases and relies upon an API that they've been told may not
>>> be stable, then they need to fix it. Again, we can boil the ocean
>>> trying to think up all the stupid things people can do with our
>>> software and try to code/process around it, but at the end of the day,
>>> you can't fix stupid.
>>
>>
>> Indeed, developers and users will forever find creative and painful
>> ways to shoot themselves in the foot and other appendages.
>>
>> Conversely, we should not hand out defective weaponry by breaking
>> Binary Compatibility (this relates to a discussion on another thread:
>> I claim it is never OK to break BC, you release a new (Java) package
>> to do the equivalent).
>
>
> I state that an alpha release (which I gather you prefer above calling it
> milestones), by definition, cannot have a 'Compatibility' claim to begin
> with, hence cannot break one either.
>
> So, are you OK with alpha releases, which do NOT claim any stability nor
> compatibility?
Yes, an alpha is an anything goes release.
Whether or not it is in a special package is a different story :)
Gary
>
>
>>
>> Gary
>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
JUnit in Action, Second Edition
Spring Batch in Action
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases
Posted by Ate Douma <at...@douma.nu>.
On 10/10/2013 03:47 PM, Gary Gregory wrote:
> On Thu, Oct 10, 2013 at 9:06 AM, James Carman
> <ja...@carmanconsulting.com> wrote:
>> On Thu, Oct 10, 2013 at 8:25 AM, Emmanuel Bourg <eb...@apache.org> wrote:
>>>
>>> I'm afraid this is more than a perceived issue, the plexus-container
>>> example given by Jörg is a very good one. Pushing drastically
>>> incompatible versions to Maven Central is not a good service for the users.
>>>
>>> I think my suggestion is a good compromise, otherwise the die-hard
>>> compatibility defenders here will never agree to publish incompatible
>>> artifacts to Maven Central.
>>>
>>
>> This gets back to my earlier comments on another thread. We can't try
>> to stupid-proof our code. If our users want to do something stupid,
>> we can't protect them from themselves. If they want to "release" code
>> which points to milestone/alpha/rc/SNAPSHOT/whatever, then that's on
>> them.
>>
>>>
>>> I agree this is annoying, but this has to be balanced with the annoyance
>>> of dealing with incompatible dependencies (for example, components
>>> depending on different versions of BouncyCastle). It's easy to rename an
>>> import in your code compared to fixing a jar hell situation.
>>>
>>
>> If a third-party library releases a version which points at one of our
>> alpha releases and relies upon an API that they've been told may not
>> be stable, then they need to fix it. Again, we can boil the ocean
>> trying to think up all the stupid things people can do with our
>> software and try to code/process around it, but at the end of the day,
>> you can't fix stupid.
>
> Indeed, developers and users will forever find creative and painful
> ways to shoot themselves in the foot and other appendages.
>
> Conversely, we should not hand out defective weaponry by breaking
> Binary Compatibility (this relates to a discussion on another thread:
> I claim it is never OK to break BC, you release a new (Java) package
> to do the equivalent).
I state that an alpha release (which I gather you prefer above calling it
milestones), by definition, cannot have a 'Compatibility' claim to begin with,
hence cannot break one either.
So, are you OK with alpha releases, which do NOT claim any stability nor
compatibility?
>
> Gary
>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases
Posted by Gary Gregory <ga...@gmail.com>.
On Thu, Oct 10, 2013 at 10:04 AM, James Carman
<ja...@carmanconsulting.com> wrote:
> I think the idea is that we don't break BC between an older full
> version and a new alpha/milestone/rc/whatever, unless of course, the
> new alpha/milestone/rc/whatever release is on a new major version.
> For example, we can have API breaks between commons-foo-1.0 and
> commons-foo-2.0-alpha. We can have API breaks between
> commons-foo-2.0-alpha1 and commons-foo-2.0-alpha2. We cannot have API
> breaks between commons-foo-2.0 and commons-foo-2.1-alpha. How does
> that sound (the concept not the choice of alpha)?
Sounds reasonable.
Gary
>
> On Thu, Oct 10, 2013 at 9:47 AM, Gary Gregory <ga...@gmail.com> wrote:
>> On Thu, Oct 10, 2013 at 9:06 AM, James Carman
>> <ja...@carmanconsulting.com> wrote:
>>> On Thu, Oct 10, 2013 at 8:25 AM, Emmanuel Bourg <eb...@apache.org> wrote:
>>>>
>>>> I'm afraid this is more than a perceived issue, the plexus-container
>>>> example given by Jörg is a very good one. Pushing drastically
>>>> incompatible versions to Maven Central is not a good service for the users.
>>>>
>>>> I think my suggestion is a good compromise, otherwise the die-hard
>>>> compatibility defenders here will never agree to publish incompatible
>>>> artifacts to Maven Central.
>>>>
>>>
>>> This gets back to my earlier comments on another thread. We can't try
>>> to stupid-proof our code. If our users want to do something stupid,
>>> we can't protect them from themselves. If they want to "release" code
>>> which points to milestone/alpha/rc/SNAPSHOT/whatever, then that's on
>>> them.
>>>
>>>>
>>>> I agree this is annoying, but this has to be balanced with the annoyance
>>>> of dealing with incompatible dependencies (for example, components
>>>> depending on different versions of BouncyCastle). It's easy to rename an
>>>> import in your code compared to fixing a jar hell situation.
>>>>
>>>
>>> If a third-party library releases a version which points at one of our
>>> alpha releases and relies upon an API that they've been told may not
>>> be stable, then they need to fix it. Again, we can boil the ocean
>>> trying to think up all the stupid things people can do with our
>>> software and try to code/process around it, but at the end of the day,
>>> you can't fix stupid.
>>
>> Indeed, developers and users will forever find creative and painful
>> ways to shoot themselves in the foot and other appendages.
>>
>> Conversely, we should not hand out defective weaponry by breaking
>> Binary Compatibility (this relates to a discussion on another thread:
>> I claim it is never OK to break BC, you release a new (Java) package
>> to do the equivalent).
>>
>> Gary
>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> Java Persistence with Hibernate, Second Edition
>> JUnit in Action, Second Edition
>> Spring Batch in Action
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
JUnit in Action, Second Edition
Spring Batch in Action
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases
Posted by James Carman <ja...@carmanconsulting.com>.
I think the idea is that we don't break BC between an older full
version and a new alpha/milestone/rc/whatever, unless of course, the
new alpha/milestone/rc/whatever release is on a new major version.
For example, we can have API breaks between commons-foo-1.0 and
commons-foo-2.0-alpha. We can have API breaks between
commons-foo-2.0-alpha1 and commons-foo-2.0-alpha2. We cannot have API
breaks between commons-foo-2.0 and commons-foo-2.1-alpha. How does
that sound (the concept not the choice of alpha)?
On Thu, Oct 10, 2013 at 9:47 AM, Gary Gregory <ga...@gmail.com> wrote:
> On Thu, Oct 10, 2013 at 9:06 AM, James Carman
> <ja...@carmanconsulting.com> wrote:
>> On Thu, Oct 10, 2013 at 8:25 AM, Emmanuel Bourg <eb...@apache.org> wrote:
>>>
>>> I'm afraid this is more than a perceived issue, the plexus-container
>>> example given by Jörg is a very good one. Pushing drastically
>>> incompatible versions to Maven Central is not a good service for the users.
>>>
>>> I think my suggestion is a good compromise, otherwise the die-hard
>>> compatibility defenders here will never agree to publish incompatible
>>> artifacts to Maven Central.
>>>
>>
>> This gets back to my earlier comments on another thread. We can't try
>> to stupid-proof our code. If our users want to do something stupid,
>> we can't protect them from themselves. If they want to "release" code
>> which points to milestone/alpha/rc/SNAPSHOT/whatever, then that's on
>> them.
>>
>>>
>>> I agree this is annoying, but this has to be balanced with the annoyance
>>> of dealing with incompatible dependencies (for example, components
>>> depending on different versions of BouncyCastle). It's easy to rename an
>>> import in your code compared to fixing a jar hell situation.
>>>
>>
>> If a third-party library releases a version which points at one of our
>> alpha releases and relies upon an API that they've been told may not
>> be stable, then they need to fix it. Again, we can boil the ocean
>> trying to think up all the stupid things people can do with our
>> software and try to code/process around it, but at the end of the day,
>> you can't fix stupid.
>
> Indeed, developers and users will forever find creative and painful
> ways to shoot themselves in the foot and other appendages.
>
> Conversely, we should not hand out defective weaponry by breaking
> Binary Compatibility (this relates to a discussion on another thread:
> I claim it is never OK to break BC, you release a new (Java) package
> to do the equivalent).
>
> Gary
>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> JUnit in Action, Second Edition
> Spring Batch in Action
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases
Posted by Gary Gregory <ga...@gmail.com>.
On Thu, Oct 10, 2013 at 9:06 AM, James Carman
<ja...@carmanconsulting.com> wrote:
> On Thu, Oct 10, 2013 at 8:25 AM, Emmanuel Bourg <eb...@apache.org> wrote:
>>
>> I'm afraid this is more than a perceived issue, the plexus-container
>> example given by Jörg is a very good one. Pushing drastically
>> incompatible versions to Maven Central is not a good service for the users.
>>
>> I think my suggestion is a good compromise, otherwise the die-hard
>> compatibility defenders here will never agree to publish incompatible
>> artifacts to Maven Central.
>>
>
> This gets back to my earlier comments on another thread. We can't try
> to stupid-proof our code. If our users want to do something stupid,
> we can't protect them from themselves. If they want to "release" code
> which points to milestone/alpha/rc/SNAPSHOT/whatever, then that's on
> them.
>
>>
>> I agree this is annoying, but this has to be balanced with the annoyance
>> of dealing with incompatible dependencies (for example, components
>> depending on different versions of BouncyCastle). It's easy to rename an
>> import in your code compared to fixing a jar hell situation.
>>
>
> If a third-party library releases a version which points at one of our
> alpha releases and relies upon an API that they've been told may not
> be stable, then they need to fix it. Again, we can boil the ocean
> trying to think up all the stupid things people can do with our
> software and try to code/process around it, but at the end of the day,
> you can't fix stupid.
Indeed, developers and users will forever find creative and painful
ways to shoot themselves in the foot and other appendages.
Conversely, we should not hand out defective weaponry by breaking
Binary Compatibility (this relates to a discussion on another thread:
I claim it is never OK to break BC, you release a new (Java) package
to do the equivalent).
Gary
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
JUnit in Action, Second Edition
Spring Batch in Action
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases
Posted by James Carman <ja...@carmanconsulting.com>.
On Thu, Oct 10, 2013 at 8:25 AM, Emmanuel Bourg <eb...@apache.org> wrote:
>
> I'm afraid this is more than a perceived issue, the plexus-container
> example given by Jörg is a very good one. Pushing drastically
> incompatible versions to Maven Central is not a good service for the users.
>
> I think my suggestion is a good compromise, otherwise the die-hard
> compatibility defenders here will never agree to publish incompatible
> artifacts to Maven Central.
>
This gets back to my earlier comments on another thread. We can't try
to stupid-proof our code. If our users want to do something stupid,
we can't protect them from themselves. If they want to "release" code
which points to milestone/alpha/rc/SNAPSHOT/whatever, then that's on
them.
>
> I agree this is annoying, but this has to be balanced with the annoyance
> of dealing with incompatible dependencies (for example, components
> depending on different versions of BouncyCastle). It's easy to rename an
> import in your code compared to fixing a jar hell situation.
>
If a third-party library releases a version which points at one of our
alpha releases and relies upon an API that they've been told may not
be stable, then they need to fix it. Again, we can boil the ocean
trying to think up all the stupid things people can do with our
software and try to code/process around it, but at the end of the day,
you can't fix stupid.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 10/10/2013 13:47, Ate Douma a écrit :
> While doing this might be somewhat automated, sure, I still would not
> favor this.
> I think it tries to solve more of a perceived than an actual problem.
I'm afraid this is more than a perceived issue, the plexus-container
example given by Jörg is a very good one. Pushing drastically
incompatible versions to Maven Central is not a good service for the users.
I think my suggestion is a good compromise, otherwise the die-hard
compatibility defenders here will never agree to publish incompatible
artifacts to Maven Central.
> And it is not convenient for the experimental end-users either, because
> they most definitely will HAVE to modify their code (manually).
I agree this is annoying, but this has to be balanced with the annoyance
of dealing with incompatible dependencies (for example, components
depending on different versions of BouncyCastle). It's easy to rename an
import in your code compared to fixing a jar hell situation.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases
Posted by Jörg Schaible <Jo...@scalaris.com>.
Hi Ate,
Ate Douma wrote:
> On 10/10/2013 01:36 PM, Emmanuel Bourg wrote:
>> Le 10/10/2013 13:26, Ate Douma a écrit :
>>
>>> Thoughts?
>>
>> A solution could be to change the package for every preview release.
>> Something like:
>>
>> org.apache.commons.experimental.<componentname><number>
>>
>> So, for CSV we could release a 0.8 and 0.9 version under the packages:
>>
>> org.apache.commons.experimental.csv8
>> org.apache.commons.experimental.csv9
>>
>> The package translation could probably be automated by the shade plugin,
>> such that we keep developing with the org.apache.commons.csv package.
>
> While doing this might be somewhat automated, sure, I still would not
> favor this. I think it tries to solve more of a perceived than an actual
> problem. And it is not convenient for the experimental end-users either,
> because they most definitely will HAVE to modify their code (manually).
I am not strictly against milestones, but it requires a strict time frame
for a final release. And I fear with all my experience gained in the years
as Commons committer, that we will fail here badly. I was myself too often
suddenly occupied with real life tasks.
The problem in Commons is that our components are often widely used and the
probability to depend transitively on different versions of the same Commons
component is very high just by using a view different components of 3rd
parties.
The problem now with long lasting milestones is that for a final release the
API might break again and suddenly you can no longer use safely those 3rd
party components together anymore, just because one of it depends
(transitively) on the milestone while all other can rely on the stable API.
IMHO Emmanuel made an interesting suggestion, but I would not take it so
far. Why not have a special package for any kind of alpha/beta/milestone
release? For CSV we would then simply have:
org.apache.commons.experimental.csv
Advantage: Early adopters might already test the API without the requirement
to 'update' the imports with every new milestone, but they are prepared to
make API adjustments anyway and they are immediately remembered that they
should not depend on the stuff in a release.
Even if some stupid vendor uses now the experimental package for its own
release, it is a lot easier afterwards to shade this package automatically
for my own product without breaking any other stuff using the final API.
Cheers,
Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases
Posted by Ate Douma <at...@douma.nu>.
On 10/10/2013 01:36 PM, Emmanuel Bourg wrote:
> Le 10/10/2013 13:26, Ate Douma a écrit :
>
>> Thoughts?
>
> A solution could be to change the package for every preview release.
> Something like:
>
> org.apache.commons.experimental.<componentname><number>
>
> So, for CSV we could release a 0.8 and 0.9 version under the packages:
>
> org.apache.commons.experimental.csv8
> org.apache.commons.experimental.csv9
>
> The package translation could probably be automated by the shade plugin,
> such that we keep developing with the org.apache.commons.csv package.
While doing this might be somewhat automated, sure, I still would not favor this.
I think it tries to solve more of a perceived than an actual problem.
And it is not convenient for the experimental end-users either, because they
most definitely will HAVE to modify their code (manually).
>
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 10/10/2013 13:26, Ate Douma a écrit :
> Thoughts?
A solution could be to change the package for every preview release.
Something like:
org.apache.commons.experimental.<componentname><number>
So, for CSV we could release a 0.8 and 0.9 version under the packages:
org.apache.commons.experimental.csv8
org.apache.commons.experimental.csv9
The package translation could probably be automated by the shade plugin,
such that we keep developing with the org.apache.commons.csv package.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
[DISCUSS] Allow unstable 0.x OR -Milestone releases [Was: [DISCUSS]
Putting several unmaintained components to dormant]
Posted by Ate Douma <at...@douma.nu>.
I've move this into a separate [DISCUSS] thread as I think it needs separate
discussion.
Jörg gave some objections below about using Milestone releases, as I proposed
earlier to support releasing intermediate versions of a not-yet-stabalized
component.
While I understand his problems with unstable versions potentially getting
'stuck' for long time, where end-users *might* start expecting them to remain
stable, I don't agree this is, or should be, the common case. Or at least not an
argument to hold against using such 0.x or -Milestone releases.
Instead, the whole point is to get project/component development moving *faster*
by allowing *experimental* end-users to provide feedback, and more flexibility
and convenience for the developers of such project/component.
The idea to have to 'switch' to a next major version for any incompatibile
change, as Jörg proposes, requiring package changes, whatnot, while a project
clearly is not ready to stabalize, really puts way too much hurdles up for both
the developers *and* such experimental end-users, as they would HAVE to change
all of their code to be able to provide AND leaverage such new 0.x or Milestone
version.
Case in point: SCXML
If we are allowed to start working on this component shortly, we intend to, and
HAVE to switch to a 1.0 version first, as there already is a 0.9 version release
out, while we will need to move to newer JDK and incompatible API changes
anyway. At the same time, getting a final/stabalized 1.0 release out most
certainly will take several iterations.
I don't want to have to wait doing an intermediate release, nor rapidly having
to switch to a 2.x/3.x/4.x/etc. versions, just because Milestone releases are
acceptable for this purpose. Where would Milestone releases [1] be useful for
otherwise, anyway?
I think a real problem might arise IF other components (or 3rd party libraries)
would start depending directly on such Milestone releases, potentially
introducing unexpected instabilities for end-users. And maybe it is worthwhile
to make such usages, at least for Commons, prohibited. That would make sense to me.
But for components like SCXML, javaflow, or csv, this I don't think would be a
real issue. Those end-users making use of these experimental components are, or
should be very well aware, of the added responsibility they take depending on a
not-yet-stabilized version, as clearly is also indicated by the version, as well
as SHOULD be prominently documented in the release notes, readme, etc.
Thoughts?
Ate
On 10/10/2013 12:45 PM, Benedikt Ritter wrote:
> I like the idea of releasing 0.x versions. A good example is [csv]. I would have no problem with releasing the current trunk as 0.9. At the moment [csv] is just another component we don't releaese because we want to come up with a perfect API (and I take responsibility for that :-)
>
> Benedikt
>
> Send from my mobile device
>
>> Am 10.10.2013 um 12:15 schrieb Jörg Schaible <Jo...@scalaris.com>:
>>
>> Hi,
>>
>> Ate Douma wrote:
>>
>>>> On 10/10/2013 12:24 AM, Torsten Curdt wrote:
>>>> Every now and then I keep getting requests via private mail asking to
>>>> release javaflow as it seems to be working for people. Yet I know there
>>>> is still so much essential stuff to fix for a 1.0 release.
>>>>
>>>> Crossing over to the other thread: I know on github I would made a 0.x
>>>> release already ages ago but knowing I won't have time to work on it
>>>> anymore I keep pushing this out at commons.
>>>
>>> Wouldn't this be a case to allow and use intermediate milestone releases?
>>>
>>> Using a 1.0-Mxx version would make still clear to the users things haven't
>>> settled yet (API wise), so should not limit or restrict making API changes
>>> before a final 1.0 release, but would help both the community and the
>>> project moving. More likely to incite further involvement and
>>> contributions, etc.
>>>
>>> Being 'stuck' on getting a (final) 1.0 release out because everything
>>> should be settled and 'frozen' (API wise) first doesn't make sense to me
>>> at all.
>>
>> We should not be so afraid to switch to 2.x if the 1.x API turns out to be
>> cumbersome in some cases. Typically you may also increase Java level in the
>> meantime and therefore eventually even have a benefit of new possibilities.
>>
>>> "Release early and often" really is what keeps open source projects moving
>>> forward, *any* policy which blocks that is plain wrong and should be
>>> fixed.
>>>
>>> Note: I'm not saying I'm against the strict versioning rules, but those
>>> should NOT block getting to a 1.0 release easily.
>>> And I don't think they do. Isn't this where Milestone releases are meant
>>> for?
>>
>> I am not a big fan of milestones unless we really have a forced schedule for
>> the final release. If we get into the situation that the milestone is the
>> latest release for months, we get into jar hell again, because that
>> milestone is then *used* like any proper release. You cannot prevent this.
>>
>> There is a reason why I have to use for a (private) Maven plugin an artifact
>> like org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9-stable-1.
>> That's a result of such a "milestone" and I really like to avoid this
>> situation for Apache Commons.
>>
>>>> Release and put into dormant?
>>>> It's a strange situation.
>>
>> No release it as 1.0 and go on with 2.x, since 1.0 is probably already based
>> on old technology.
>>
>> - Jörg
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Putting several unmaintained components to dormant
Posted by Benedikt Ritter <be...@gmail.com>.
I like the idea of releasing 0.x versions. A good example is [csv]. I would have no problem with releasing the current trunk as 0.9. At the moment [csv] is just another component we don't releaese because we want to come up with a perfect API (and I take responsibility for that :-)
Benedikt
Send from my mobile device
> Am 10.10.2013 um 12:15 schrieb Jörg Schaible <Jo...@scalaris.com>:
>
> Hi,
>
> Ate Douma wrote:
>
>>> On 10/10/2013 12:24 AM, Torsten Curdt wrote:
>>> Every now and then I keep getting requests via private mail asking to
>>> release javaflow as it seems to be working for people. Yet I know there
>>> is still so much essential stuff to fix for a 1.0 release.
>>>
>>> Crossing over to the other thread: I know on github I would made a 0.x
>>> release already ages ago but knowing I won't have time to work on it
>>> anymore I keep pushing this out at commons.
>>
>> Wouldn't this be a case to allow and use intermediate milestone releases?
>>
>> Using a 1.0-Mxx version would make still clear to the users things haven't
>> settled yet (API wise), so should not limit or restrict making API changes
>> before a final 1.0 release, but would help both the community and the
>> project moving. More likely to incite further involvement and
>> contributions, etc.
>>
>> Being 'stuck' on getting a (final) 1.0 release out because everything
>> should be settled and 'frozen' (API wise) first doesn't make sense to me
>> at all.
>
> We should not be so afraid to switch to 2.x if the 1.x API turns out to be
> cumbersome in some cases. Typically you may also increase Java level in the
> meantime and therefore eventually even have a benefit of new possibilities.
>
>> "Release early and often" really is what keeps open source projects moving
>> forward, *any* policy which blocks that is plain wrong and should be
>> fixed.
>>
>> Note: I'm not saying I'm against the strict versioning rules, but those
>> should NOT block getting to a 1.0 release easily.
>> And I don't think they do. Isn't this where Milestone releases are meant
>> for?
>
> I am not a big fan of milestones unless we really have a forced schedule for
> the final release. If we get into the situation that the milestone is the
> latest release for months, we get into jar hell again, because that
> milestone is then *used* like any proper release. You cannot prevent this.
>
> There is a reason why I have to use for a (private) Maven plugin an artifact
> like org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9-stable-1.
> That's a result of such a "milestone" and I really like to avoid this
> situation for Apache Commons.
>
>>> Release and put into dormant?
>>> It's a strange situation.
>
> No release it as 1.0 and go on with 2.x, since 1.0 is probably already based
> on old technology.
>
> - Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Putting several unmaintained components to dormant
Posted by Jörg Schaible <Jo...@scalaris.com>.
Hi,
Ate Douma wrote:
> On 10/10/2013 12:24 AM, Torsten Curdt wrote:
>> Every now and then I keep getting requests via private mail asking to
>> release javaflow as it seems to be working for people. Yet I know there
>> is still so much essential stuff to fix for a 1.0 release.
>>
>> Crossing over to the other thread: I know on github I would made a 0.x
>> release already ages ago but knowing I won't have time to work on it
>> anymore I keep pushing this out at commons.
>
> Wouldn't this be a case to allow and use intermediate milestone releases?
>
> Using a 1.0-Mxx version would make still clear to the users things haven't
> settled yet (API wise), so should not limit or restrict making API changes
> before a final 1.0 release, but would help both the community and the
> project moving. More likely to incite further involvement and
> contributions, etc.
>
> Being 'stuck' on getting a (final) 1.0 release out because everything
> should be settled and 'frozen' (API wise) first doesn't make sense to me
> at all.
We should not be so afraid to switch to 2.x if the 1.x API turns out to be
cumbersome in some cases. Typically you may also increase Java level in the
meantime and therefore eventually even have a benefit of new possibilities.
> "Release early and often" really is what keeps open source projects moving
> forward, *any* policy which blocks that is plain wrong and should be
> fixed.
>
> Note: I'm not saying I'm against the strict versioning rules, but those
> should NOT block getting to a 1.0 release easily.
> And I don't think they do. Isn't this where Milestone releases are meant
> for?
I am not a big fan of milestones unless we really have a forced schedule for
the final release. If we get into the situation that the milestone is the
latest release for months, we get into jar hell again, because that
milestone is then *used* like any proper release. You cannot prevent this.
There is a reason why I have to use for a (private) Maven plugin an artifact
like org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9-stable-1.
That's a result of such a "milestone" and I really like to avoid this
situation for Apache Commons.
>> Release and put into dormant?
>> It's a strange situation.
No release it as 1.0 and go on with 2.x, since 1.0 is probably already based
on old technology.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Putting several unmaintained components to dormant
Posted by Ate Douma <at...@douma.nu>.
On 10/10/2013 12:24 AM, Torsten Curdt wrote:
> Every now and then I keep getting requests via private mail asking to
> release javaflow as it seems to be working for people. Yet I know there is
> still so much essential stuff to fix for a 1.0 release.
>
> Crossing over to the other thread: I know on github I would made a 0.x
> release already ages ago but knowing I won't have time to work on it
> anymore I keep pushing this out at commons.
Wouldn't this be a case to allow and use intermediate milestone releases?
Using a 1.0-Mxx version would make still clear to the users things haven't
settled yet (API wise), so should not limit or restrict making API changes
before a final 1.0 release, but would help both the community and the project
moving. More likely to incite further involvement and contributions, etc.
Being 'stuck' on getting a (final) 1.0 release out because everything should be
settled and 'frozen' (API wise) first doesn't make sense to me at all.
"Release early and often" really is what keeps open source projects moving
forward, *any* policy which blocks that is plain wrong and should be fixed.
Note: I'm not saying I'm against the strict versioning rules, but those should
NOT block getting to a 1.0 release easily.
And I don't think they do. Isn't this where Milestone releases are meant for?
Ate
>
> Release and put into dormant?
> It's a strange situation.
>
> cheers,
> Torsten
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Putting several unmaintained components to dormant
Posted by Torsten Curdt <tc...@vafer.org>.
Every now and then I keep getting requests via private mail asking to
release javaflow as it seems to be working for people. Yet I know there is
still so much essential stuff to fix for a 1.0 release.
Crossing over to the other thread: I know on github I would made a 0.x
release already ages ago but knowing I won't have time to work on it
anymore I keep pushing this out at commons.
Release and put into dormant?
It's a strange situation.
cheers,
Torsten
Re: [DISCUSS] Putting several unmaintained components to dormant
Posted by Dan Tran <da...@gmail.com>.
I am a active VFS user wishing to have an official VFS 2.1 release :-)
Sorry about the noise.
-Dan
On Wed, Oct 9, 2013 at 2:53 PM, Gary Gregory <ga...@gmail.com> wrote:
> On Wed, Oct 9, 2013 at 4:35 PM, Jörg Schaible <jo...@gmx.de>
> wrote:
> > Dan Tran wrote:
> >
> >> VFS has no release for a couple of years. Would you consider it as
> proper?
> >
> > Just because there was no release, does not mean there have been no
> > development. Check svn if you don't believe.
>
> I consider VFS active. I just have not taken the time to push a 2.1 out.
>
> Gary
>
>
> >
> > - Jörg
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> JUnit in Action, Second Edition
> Spring Batch in Action
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [DISCUSS] Putting several unmaintained components to dormant
Posted by Gary Gregory <ga...@gmail.com>.
On Wed, Oct 9, 2013 at 4:35 PM, Jörg Schaible <jo...@gmx.de> wrote:
> Dan Tran wrote:
>
>> VFS has no release for a couple of years. Would you consider it as proper?
>
> Just because there was no release, does not mean there have been no
> development. Check svn if you don't believe.
I consider VFS active. I just have not taken the time to push a 2.1 out.
Gary
>
> - Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
JUnit in Action, Second Edition
Spring Batch in Action
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Putting several unmaintained components to dormant
Posted by Jörg Schaible <jo...@gmx.de>.
Dan Tran wrote:
> VFS has no release for a couple of years. Would you consider it as proper?
Just because there was no release, does not mean there have been no
development. Check svn if you don't believe.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Putting several unmaintained components to dormant
Posted by Dan Tran <da...@gmail.com>.
VFS has no release for a couple of years. Would you consider it as proper?
-D
On Wed, Oct 9, 2013 at 12:17 PM, Benedikt Ritter <br...@apache.org> wrote:
> Hi,
>
> I think Phil came up with the idea to try to focus on the components that
> we are able to maintain and put all other stuff to dormant. Here is the
> list of components that I think really are proper:
>
> - CLI
> - Codec
> - Collections
> - Compress
> - Configuration
> - CSV
> - Daemon
> - DBCP (?)
> - Email
> - Functor
> - Imaging (?)
> - IO
> - JCI
> - Lang
> - Logging
> - Math
> - Net
> - Pool (?)
> - Proxy
> - SCXML (after recent interest)
> - VFS
> - Weaver
>
> All other stuff can go dormant because there is currently nobody who
> maintains it. Still a pretty long list. Thoughts? Anything missing?
>
> Benedikt
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
>
Re: [DISCUSS] Putting several unmaintained components to dormant
Posted by Oliver Heger <ol...@oliver-heger.de>.
Am 09.10.2013 21:17, schrieb Benedikt Ritter:
> Hi,
>
> I think Phil came up with the idea to try to focus on the components that
> we are able to maintain and put all other stuff to dormant. Here is the
> list of components that I think really are proper:
>
> - CLI
> - Codec
> - Collections
> - Compress
> - Configuration
> - CSV
> - Daemon
> - DBCP (?)
> - Email
> - Functor
> - Imaging (?)
> - IO
> - JCI
> - Lang
> - Logging
> - Math
> - Net
> - Pool (?)
> - Proxy
> - SCXML (after recent interest)
> - VFS
> - Weaver
>
> All other stuff can go dormant because there is currently nobody who
> maintains it. Still a pretty long list. Thoughts? Anything missing?
I would like to get another release of BeanUtils out because there is a
dependency to the current work on Configuration. After that I am
interested in working on BeanUtils2 (in the sandbox).
Oliver
>
> Benedikt
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Putting several unmaintained components to dormant
Posted by Henri Yandell <fl...@gmail.com>.
+1 to Phil's +1 meaning. :)
On Monday, October 14, 2013, Phil Steitz wrote:
> On 10/14/13 9:18 AM, Benedikt Ritter wrote:
> > The nice thing about Hen's solution is, that I expect it to be better
> > structured. When 20 people begin voting on 30 different components it
> will
> > get confusing in that thread. Having one single file which contains the
> > result of the vote would be very easy.
> >
> > How do you want to reach non commons committers? By announcing on
> > community@? Or were you talking about those who lurk around on the ML
> > anyway :-)
>
> Via this mailing list. I agree that to bootstrap we need a combined
> poll of some kind. A wiki page that anyone could edit might work.
> Or use Hen's svn idea and have people just chime in on list and one
> of us does the commit to add them. The main thing to agree on is
> what it means to add your name / vote +1 and what minimums we are
> going to require. And then once we have the initial pruning done,
> how do we keep from backsliding into current state. That is what my
> 0) - 2) were referring to.
>
> Phil
> >
> > Benedikt
> >
> >
> > 2013/10/14 Phil Steitz <ph...@gmail.com>
> >
> >> On 10/14/13 2:04 AM, Henri Yandell wrote:
> >>> Wearing my old Attic fart hat - something is dead when there is no one
> >> left
> >>> to turn the light out. Something is inactive when it couldn't pass a
> vote
> >>> to keep the project alive (ie: 3 +1s).
> >>>
> >>> So that's one way to do this. Make a file in SVN. Put each component in
> >> it
> >>> (include the sandbox perhaps). Ask everyone to vote by putting their
> name
> >>> next to a component.
> >>>
> >>> Any component failing to get 3 names is a goner [aka up for debate, but
> >> the
> >>> point of the debate is to convince others to add their name to the
> >>> component]. Any component with zero names is a goner, kaput, deceased.
> >> Sounds good to me, with some slight changes. I think non-committers
> >> - especially ASF committers who are not commons committers - should
> >> be able to vote (with meaning as described below). I was about to
> >> propose something similar to get the initial pruning done, and then
> >> an ongoing process like:
> >>
> >> 0) Anyone can present a "dormancy challenge" at any time for a
> >> component that they think might be dormant. Just start a thread
> >> with subject [DORMANT][FOO] (content optional).
> >> 1) We allow a nice long time for people to chime in - say two
> >> weeks. If an ASF committer volunteers to RM a (future) release, or
> >> if at least 2 people signal intent to do material work on [FOO], the
> >> challenge fails and [FOO] remains active; otherwise it is lazily
> >> deemed dormant.
> >> 2) Reviving a dormant component requires nothing more than the
> >> action awaited in 1). Dormant components stay put in svn, but their
> >> websites and the main commons site designate them as dormant.
> >>
> >> So basically, you are presenting a challenge for "all" components to
> >> start. I am +1 for that. The key question is what exactly does it
> >> mean to vote +1 for a component. It can't mean "we should keep it
> >> alive." To be meaningful, it has to mean "I am going to work on
> >> it." I would rather be more hard core on what +1 means and tolerant
> >> of only 2 +1s, especially if one of them is stepping up to RM.
> >>
> >> Phil
> >>
> >> Hen On Wed, Oct 9, 2013 at 12:17 PM, Benedikt Ritter
> >> <br...@apache.org> wrote:
> >>>> Hi,
> >>>>
> >>>> I think Phil came up with the idea to try to focus on the components
> >> that
> >>>> we are able to maintain and put all other stuff to dormant. Here is
> the
> >>>> list of components that I think really are proper:
> >>>>
> >>>> - CLI
> >>>> - Codec
> >>>> - Collections
> >>>> - Compress
> >>>> - Configuration
> >>>> - CSV
> >>>> - Daemon
> >>>> - DBCP (?)
> >>>> - Email
> >>>> - Functor
> >>>> - Imaging (?)
> >>>> - IO
> >>>> - JCI
> >>>> - Lang
> >>>> - Logging
> >>>> - Math
> >>>> - Net
> >>>> - Pool (?)
> >>>> - Proxy
> >>>> - SCXML (after recent interest)
> >>>> - VFS
> >>>> - Weaver
> >>>>
> >>>> All other stuff can go dormant because there is currently nobody who
> >>>> maintains it. Still a pretty long list. Thoughts? Anything missing?
> >>>>
> >>>> Benedikt
> >>>>
> >>>> --
> >>>> http://people.apache.org/~britter/
> >>>> http://www.systemoutprintln.de/
> >>>> http://twitter.com/BenediktRitter
> >>>> http://github.com/britter
> >>>>
> >>
> >> ------------------------------------------------------
Re: [DISCUSS] Putting several unmaintained components to dormant
Posted by Phil Steitz <ph...@gmail.com>.
On 10/14/13 9:18 AM, Benedikt Ritter wrote:
> The nice thing about Hen's solution is, that I expect it to be better
> structured. When 20 people begin voting on 30 different components it will
> get confusing in that thread. Having one single file which contains the
> result of the vote would be very easy.
>
> How do you want to reach non commons committers? By announcing on
> community@? Or were you talking about those who lurk around on the ML
> anyway :-)
Via this mailing list. I agree that to bootstrap we need a combined
poll of some kind. A wiki page that anyone could edit might work.
Or use Hen's svn idea and have people just chime in on list and one
of us does the commit to add them. The main thing to agree on is
what it means to add your name / vote +1 and what minimums we are
going to require. And then once we have the initial pruning done,
how do we keep from backsliding into current state. That is what my
0) - 2) were referring to.
Phil
>
> Benedikt
>
>
> 2013/10/14 Phil Steitz <ph...@gmail.com>
>
>> On 10/14/13 2:04 AM, Henri Yandell wrote:
>>> Wearing my old Attic fart hat - something is dead when there is no one
>> left
>>> to turn the light out. Something is inactive when it couldn't pass a vote
>>> to keep the project alive (ie: 3 +1s).
>>>
>>> So that's one way to do this. Make a file in SVN. Put each component in
>> it
>>> (include the sandbox perhaps). Ask everyone to vote by putting their name
>>> next to a component.
>>>
>>> Any component failing to get 3 names is a goner [aka up for debate, but
>> the
>>> point of the debate is to convince others to add their name to the
>>> component]. Any component with zero names is a goner, kaput, deceased.
>> Sounds good to me, with some slight changes. I think non-committers
>> - especially ASF committers who are not commons committers - should
>> be able to vote (with meaning as described below). I was about to
>> propose something similar to get the initial pruning done, and then
>> an ongoing process like:
>>
>> 0) Anyone can present a "dormancy challenge" at any time for a
>> component that they think might be dormant. Just start a thread
>> with subject [DORMANT][FOO] (content optional).
>> 1) We allow a nice long time for people to chime in - say two
>> weeks. If an ASF committer volunteers to RM a (future) release, or
>> if at least 2 people signal intent to do material work on [FOO], the
>> challenge fails and [FOO] remains active; otherwise it is lazily
>> deemed dormant.
>> 2) Reviving a dormant component requires nothing more than the
>> action awaited in 1). Dormant components stay put in svn, but their
>> websites and the main commons site designate them as dormant.
>>
>> So basically, you are presenting a challenge for "all" components to
>> start. I am +1 for that. The key question is what exactly does it
>> mean to vote +1 for a component. It can't mean "we should keep it
>> alive." To be meaningful, it has to mean "I am going to work on
>> it." I would rather be more hard core on what +1 means and tolerant
>> of only 2 +1s, especially if one of them is stepping up to RM.
>>
>> Phil
>>
>> Hen On Wed, Oct 9, 2013 at 12:17 PM, Benedikt Ritter
>> <br...@apache.org> wrote:
>>>> Hi,
>>>>
>>>> I think Phil came up with the idea to try to focus on the components
>> that
>>>> we are able to maintain and put all other stuff to dormant. Here is the
>>>> list of components that I think really are proper:
>>>>
>>>> - CLI
>>>> - Codec
>>>> - Collections
>>>> - Compress
>>>> - Configuration
>>>> - CSV
>>>> - Daemon
>>>> - DBCP (?)
>>>> - Email
>>>> - Functor
>>>> - Imaging (?)
>>>> - IO
>>>> - JCI
>>>> - Lang
>>>> - Logging
>>>> - Math
>>>> - Net
>>>> - Pool (?)
>>>> - Proxy
>>>> - SCXML (after recent interest)
>>>> - VFS
>>>> - Weaver
>>>>
>>>> All other stuff can go dormant because there is currently nobody who
>>>> maintains it. Still a pretty long list. Thoughts? Anything missing?
>>>>
>>>> Benedikt
>>>>
>>>> --
>>>> http://people.apache.org/~britter/
>>>> http://www.systemoutprintln.de/
>>>> http://twitter.com/BenediktRitter
>>>> http://github.com/britter
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>> --
>> http://people.apache.org/~britter/
>> http://www.systemoutprintln.de/
>> http://twitter.com/BenediktRitter
>> http://github.com/britter
>> <de...@commons.apache.org>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Putting several unmaintained components to dormant
Posted by Benedikt Ritter <br...@apache.org>.
The nice thing about Hen's solution is, that I expect it to be better
structured. When 20 people begin voting on 30 different components it will
get confusing in that thread. Having one single file which contains the
result of the vote would be very easy.
How do you want to reach non commons committers? By announcing on
community@? Or were you talking about those who lurk around on the ML
anyway :-)
Benedikt
2013/10/14 Phil Steitz <ph...@gmail.com>
> On 10/14/13 2:04 AM, Henri Yandell wrote:
> > Wearing my old Attic fart hat - something is dead when there is no one
> left
> > to turn the light out. Something is inactive when it couldn't pass a vote
> > to keep the project alive (ie: 3 +1s).
> >
> > So that's one way to do this. Make a file in SVN. Put each component in
> it
> > (include the sandbox perhaps). Ask everyone to vote by putting their name
> > next to a component.
> >
> > Any component failing to get 3 names is a goner [aka up for debate, but
> the
> > point of the debate is to convince others to add their name to the
> > component]. Any component with zero names is a goner, kaput, deceased.
>
> Sounds good to me, with some slight changes. I think non-committers
> - especially ASF committers who are not commons committers - should
> be able to vote (with meaning as described below). I was about to
> propose something similar to get the initial pruning done, and then
> an ongoing process like:
>
> 0) Anyone can present a "dormancy challenge" at any time for a
> component that they think might be dormant. Just start a thread
> with subject [DORMANT][FOO] (content optional).
> 1) We allow a nice long time for people to chime in - say two
> weeks. If an ASF committer volunteers to RM a (future) release, or
> if at least 2 people signal intent to do material work on [FOO], the
> challenge fails and [FOO] remains active; otherwise it is lazily
> deemed dormant.
> 2) Reviving a dormant component requires nothing more than the
> action awaited in 1). Dormant components stay put in svn, but their
> websites and the main commons site designate them as dormant.
>
> So basically, you are presenting a challenge for "all" components to
> start. I am +1 for that. The key question is what exactly does it
> mean to vote +1 for a component. It can't mean "we should keep it
> alive." To be meaningful, it has to mean "I am going to work on
> it." I would rather be more hard core on what +1 means and tolerant
> of only 2 +1s, especially if one of them is stepping up to RM.
>
> Phil
>
> Hen On Wed, Oct 9, 2013 at 12:17 PM, Benedikt Ritter
> <br...@apache.org> wrote:
> >> Hi,
> >>
> >> I think Phil came up with the idea to try to focus on the components
> that
> >> we are able to maintain and put all other stuff to dormant. Here is the
> >> list of components that I think really are proper:
> >>
> >> - CLI
> >> - Codec
> >> - Collections
> >> - Compress
> >> - Configuration
> >> - CSV
> >> - Daemon
> >> - DBCP (?)
> >> - Email
> >> - Functor
> >> - Imaging (?)
> >> - IO
> >> - JCI
> >> - Lang
> >> - Logging
> >> - Math
> >> - Net
> >> - Pool (?)
> >> - Proxy
> >> - SCXML (after recent interest)
> >> - VFS
> >> - Weaver
> >>
> >> All other stuff can go dormant because there is currently nobody who
> >> maintains it. Still a pretty long list. Thoughts? Anything missing?
> >>
> >> Benedikt
> >>
> >> --
> >> http://people.apache.org/~britter/
> >> http://www.systemoutprintln.de/
> >> http://twitter.com/BenediktRitter
> >> http://github.com/britter
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
> <de...@commons.apache.org>
>
Re: [DISCUSS] Putting several unmaintained components to dormant
Posted by Phil Steitz <ph...@gmail.com>.
On 10/14/13 2:04 AM, Henri Yandell wrote:
> Wearing my old Attic fart hat - something is dead when there is no one left
> to turn the light out. Something is inactive when it couldn't pass a vote
> to keep the project alive (ie: 3 +1s).
>
> So that's one way to do this. Make a file in SVN. Put each component in it
> (include the sandbox perhaps). Ask everyone to vote by putting their name
> next to a component.
>
> Any component failing to get 3 names is a goner [aka up for debate, but the
> point of the debate is to convince others to add their name to the
> component]. Any component with zero names is a goner, kaput, deceased.
Sounds good to me, with some slight changes. I think non-committers
- especially ASF committers who are not commons committers - should
be able to vote (with meaning as described below). I was about to
propose something similar to get the initial pruning done, and then
an ongoing process like:
0) Anyone can present a "dormancy challenge" at any time for a
component that they think might be dormant. Just start a thread
with subject [DORMANT][FOO] (content optional).
1) We allow a nice long time for people to chime in - say two
weeks. If an ASF committer volunteers to RM a (future) release, or
if at least 2 people signal intent to do material work on [FOO], the
challenge fails and [FOO] remains active; otherwise it is lazily
deemed dormant.
2) Reviving a dormant component requires nothing more than the
action awaited in 1). Dormant components stay put in svn, but their
websites and the main commons site designate them as dormant.
So basically, you are presenting a challenge for "all" components to
start. I am +1 for that. The key question is what exactly does it
mean to vote +1 for a component. It can't mean "we should keep it
alive." To be meaningful, it has to mean "I am going to work on
it." I would rather be more hard core on what +1 means and tolerant
of only 2 +1s, especially if one of them is stepping up to RM.
Phil
Hen On Wed, Oct 9, 2013 at 12:17 PM, Benedikt Ritter
<br...@apache.org> wrote:
>> Hi,
>>
>> I think Phil came up with the idea to try to focus on the components that
>> we are able to maintain and put all other stuff to dormant. Here is the
>> list of components that I think really are proper:
>>
>> - CLI
>> - Codec
>> - Collections
>> - Compress
>> - Configuration
>> - CSV
>> - Daemon
>> - DBCP (?)
>> - Email
>> - Functor
>> - Imaging (?)
>> - IO
>> - JCI
>> - Lang
>> - Logging
>> - Math
>> - Net
>> - Pool (?)
>> - Proxy
>> - SCXML (after recent interest)
>> - VFS
>> - Weaver
>>
>> All other stuff can go dormant because there is currently nobody who
>> maintains it. Still a pretty long list. Thoughts? Anything missing?
>>
>> Benedikt
>>
>> --
>> http://people.apache.org/~britter/
>> http://www.systemoutprintln.de/
>> http://twitter.com/BenediktRitter
>> http://github.com/britter
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Putting several unmaintained components to dormant
Posted by Henri Yandell <fl...@gmail.com>.
Wearing my old Attic fart hat - something is dead when there is no one left
to turn the light out. Something is inactive when it couldn't pass a vote
to keep the project alive (ie: 3 +1s).
So that's one way to do this. Make a file in SVN. Put each component in it
(include the sandbox perhaps). Ask everyone to vote by putting their name
next to a component.
Any component failing to get 3 names is a goner [aka up for debate, but the
point of the debate is to convince others to add their name to the
component]. Any component with zero names is a goner, kaput, deceased.
Hen
On Wed, Oct 9, 2013 at 12:17 PM, Benedikt Ritter <br...@apache.org> wrote:
> Hi,
>
> I think Phil came up with the idea to try to focus on the components that
> we are able to maintain and put all other stuff to dormant. Here is the
> list of components that I think really are proper:
>
> - CLI
> - Codec
> - Collections
> - Compress
> - Configuration
> - CSV
> - Daemon
> - DBCP (?)
> - Email
> - Functor
> - Imaging (?)
> - IO
> - JCI
> - Lang
> - Logging
> - Math
> - Net
> - Pool (?)
> - Proxy
> - SCXML (after recent interest)
> - VFS
> - Weaver
>
> All other stuff can go dormant because there is currently nobody who
> maintains it. Still a pretty long list. Thoughts? Anything missing?
>
> Benedikt
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
>
Re: [DISCUSS] Putting several unmaintained components to dormant
Posted by Benedikt Ritter <br...@apache.org>.
This isn't really an analysis. This is just the list of components that
belong to proper to me. If you thing that something is missing (for what
ever reason) feel free to add it. It's not like we're putting everything
directly to dormant that's not on the list. I just wanted to get a
discussion started ;-)
2013/10/9 Adrian Crum <ad...@sandglass-software.com>
> Can we include commit activity and Jira activity in the analysis?
>
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
> On 10/9/2013 1:04 PM, Benedikt Ritter wrote:
>
>> I've looked at all the proper components and listed all components where
>> I've seen activity since I'm subscribed to the ML.
>>
>>
>> 2013/10/9 Adrian Crum <ad...@sandglass-software.com>
>> >
>>
>> What criteria are you using to come up with this list?
>>>
>>> Adrian Crum
>>> Sandglass Software
>>> www.sandglass-software.com
>>>
>>>
>>> On 10/9/2013 12:17 PM, Benedikt Ritter wrote:
>>>
>>> Hi,
>>>>
>>>> I think Phil came up with the idea to try to focus on the components
>>>> that
>>>> we are able to maintain and put all other stuff to dormant. Here is the
>>>> list of components that I think really are proper:
>>>>
>>>> - CLI
>>>> - Codec
>>>> - Collections
>>>> - Compress
>>>> - Configuration
>>>> - CSV
>>>> - Daemon
>>>> - DBCP (?)
>>>> - Email
>>>> - Functor
>>>> - Imaging (?)
>>>> - IO
>>>> - JCI
>>>> - Lang
>>>> - Logging
>>>> - Math
>>>> - Net
>>>> - Pool (?)
>>>> - Proxy
>>>> - SCXML (after recent interest)
>>>> - VFS
>>>> - Weaver
>>>>
>>>> All other stuff can go dormant because there is currently nobody who
>>>> maintains it. Still a pretty long list. Thoughts? Anything missing?
>>>>
>>>> Benedikt
>>>>
>>>>
>>>> ------------------------------****----------------------------**
>>> --**---------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apac**he.org<http://apache.org>
>>> <de...@commons.apache.org>
>>> >
>>>
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>>
>>
>>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<de...@commons.apache.org>
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Re: [DISCUSS] Putting several unmaintained components to dormant
Posted by Adrian Crum <ad...@sandglass-software.com>.
That is a good point. Those Commons GPG commits are just Maven black box
updates.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 10/9/2013 1:28 PM, Christian Grobmeier wrote:
> Here is some commit activity:
>
> http://svnsearch.org/svnsearch/repos/ASF/search?view=plot&from=20130101&to=20131009&path=%2Fcommons%2Fproper&plotsort=%24plotsort
>
> But we should to exclude "typo" fixes and such.
>
> For example:
> http://svnsearch.org/svnsearch/repos/ASF/search?view=resultlist&from=20130101&to=20131009&path=%2Fcommons%2Fproper%2Fcommons-gpg-plugin&plotsort=%24plotsort
>
> 22 changes on commons gpg, but not really meaningful changes. I would
> not consider Commons GPG as maintained.
>
> Jira doesn't mean much to me. Users can submit issues, but this doesn't
> mean a component is maintained. Even when 20 issues were submitted for
> GPG, it would not consider it maintained.
>
>
>
>
> On 9 Oct 2013, at 22:06, Adrian Crum wrote:
>
>> Can we include commit activity and Jira activity in the analysis?
>>
>> Adrian Crum
>> Sandglass Software
>> www.sandglass-software.com
>>
>> On 10/9/2013 1:04 PM, Benedikt Ritter wrote:
>>> I've looked at all the proper components and listed all components where
>>> I've seen activity since I'm subscribed to the ML.
>>>
>>>
>>> 2013/10/9 Adrian Crum <ad...@sandglass-software.com>
>>>
>>>> What criteria are you using to come up with this list?
>>>>
>>>> Adrian Crum
>>>> Sandglass Software
>>>> www.sandglass-software.com
>>>>
>>>>
>>>> On 10/9/2013 12:17 PM, Benedikt Ritter wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I think Phil came up with the idea to try to focus on the
>>>>> components that
>>>>> we are able to maintain and put all other stuff to dormant. Here is
>>>>> the
>>>>> list of components that I think really are proper:
>>>>>
>>>>> - CLI
>>>>> - Codec
>>>>> - Collections
>>>>> - Compress
>>>>> - Configuration
>>>>> - CSV
>>>>> - Daemon
>>>>> - DBCP (?)
>>>>> - Email
>>>>> - Functor
>>>>> - Imaging (?)
>>>>> - IO
>>>>> - JCI
>>>>> - Lang
>>>>> - Logging
>>>>> - Math
>>>>> - Net
>>>>> - Pool (?)
>>>>> - Proxy
>>>>> - SCXML (after recent interest)
>>>>> - VFS
>>>>> - Weaver
>>>>>
>>>>> All other stuff can go dormant because there is currently nobody who
>>>>> maintains it. Still a pretty long list. Thoughts? Anything missing?
>>>>>
>>>>> Benedikt
>>>>>
>>>>>
>>>> ------------------------------**------------------------------**---------
>>>>
>>>> To unsubscribe, e-mail:
>>>> dev-unsubscribe@commons.**apache.org<de...@commons.apache.org>
>>>>
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>
>
> ---
> http://www.grobmeier.de
> @grobmeier
> GPG: 0xA5CC90DB
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Putting several unmaintained components to dormant
Posted by Christian Grobmeier <gr...@gmail.com>.
Here is some commit activity:
http://svnsearch.org/svnsearch/repos/ASF/search?view=plot&from=20130101&to=20131009&path=%2Fcommons%2Fproper&plotsort=%24plotsort
But we should to exclude "typo" fixes and such.
For example:
http://svnsearch.org/svnsearch/repos/ASF/search?view=resultlist&from=20130101&to=20131009&path=%2Fcommons%2Fproper%2Fcommons-gpg-plugin&plotsort=%24plotsort
22 changes on commons gpg, but not really meaningful changes. I would
not consider Commons GPG as maintained.
Jira doesn't mean much to me. Users can submit issues, but this doesn't
mean a component is maintained. Even when 20 issues were submitted for
GPG, it would not consider it maintained.
On 9 Oct 2013, at 22:06, Adrian Crum wrote:
> Can we include commit activity and Jira activity in the analysis?
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
> On 10/9/2013 1:04 PM, Benedikt Ritter wrote:
>> I've looked at all the proper components and listed all components
>> where
>> I've seen activity since I'm subscribed to the ML.
>>
>>
>> 2013/10/9 Adrian Crum <ad...@sandglass-software.com>
>>
>>> What criteria are you using to come up with this list?
>>>
>>> Adrian Crum
>>> Sandglass Software
>>> www.sandglass-software.com
>>>
>>>
>>> On 10/9/2013 12:17 PM, Benedikt Ritter wrote:
>>>
>>>> Hi,
>>>>
>>>> I think Phil came up with the idea to try to focus on the
>>>> components that
>>>> we are able to maintain and put all other stuff to dormant. Here is
>>>> the
>>>> list of components that I think really are proper:
>>>>
>>>> - CLI
>>>> - Codec
>>>> - Collections
>>>> - Compress
>>>> - Configuration
>>>> - CSV
>>>> - Daemon
>>>> - DBCP (?)
>>>> - Email
>>>> - Functor
>>>> - Imaging (?)
>>>> - IO
>>>> - JCI
>>>> - Lang
>>>> - Logging
>>>> - Math
>>>> - Net
>>>> - Pool (?)
>>>> - Proxy
>>>> - SCXML (after recent interest)
>>>> - VFS
>>>> - Weaver
>>>>
>>>> All other stuff can go dormant because there is currently nobody
>>>> who
>>>> maintains it. Still a pretty long list. Thoughts? Anything missing?
>>>>
>>>> Benedikt
>>>>
>>>>
>>> ------------------------------**------------------------------**---------
>>> To unsubscribe, e-mail:
>>> dev-unsubscribe@commons.**apache.org<de...@commons.apache.org>
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
---
http://www.grobmeier.de
@grobmeier
GPG: 0xA5CC90DB
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Putting several unmaintained components to dormant
Posted by Adrian Crum <ad...@sandglass-software.com>.
Can we include commit activity and Jira activity in the analysis?
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 10/9/2013 1:04 PM, Benedikt Ritter wrote:
> I've looked at all the proper components and listed all components where
> I've seen activity since I'm subscribed to the ML.
>
>
> 2013/10/9 Adrian Crum <ad...@sandglass-software.com>
>
>> What criteria are you using to come up with this list?
>>
>> Adrian Crum
>> Sandglass Software
>> www.sandglass-software.com
>>
>>
>> On 10/9/2013 12:17 PM, Benedikt Ritter wrote:
>>
>>> Hi,
>>>
>>> I think Phil came up with the idea to try to focus on the components that
>>> we are able to maintain and put all other stuff to dormant. Here is the
>>> list of components that I think really are proper:
>>>
>>> - CLI
>>> - Codec
>>> - Collections
>>> - Compress
>>> - Configuration
>>> - CSV
>>> - Daemon
>>> - DBCP (?)
>>> - Email
>>> - Functor
>>> - Imaging (?)
>>> - IO
>>> - JCI
>>> - Lang
>>> - Logging
>>> - Math
>>> - Net
>>> - Pool (?)
>>> - Proxy
>>> - SCXML (after recent interest)
>>> - VFS
>>> - Weaver
>>>
>>> All other stuff can go dormant because there is currently nobody who
>>> maintains it. Still a pretty long list. Thoughts? Anything missing?
>>>
>>> Benedikt
>>>
>>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<de...@commons.apache.org>
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Putting several unmaintained components to dormant
Posted by Benedikt Ritter <br...@apache.org>.
I've looked at all the proper components and listed all components where
I've seen activity since I'm subscribed to the ML.
2013/10/9 Adrian Crum <ad...@sandglass-software.com>
> What criteria are you using to come up with this list?
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
>
> On 10/9/2013 12:17 PM, Benedikt Ritter wrote:
>
>> Hi,
>>
>> I think Phil came up with the idea to try to focus on the components that
>> we are able to maintain and put all other stuff to dormant. Here is the
>> list of components that I think really are proper:
>>
>> - CLI
>> - Codec
>> - Collections
>> - Compress
>> - Configuration
>> - CSV
>> - Daemon
>> - DBCP (?)
>> - Email
>> - Functor
>> - Imaging (?)
>> - IO
>> - JCI
>> - Lang
>> - Logging
>> - Math
>> - Net
>> - Pool (?)
>> - Proxy
>> - SCXML (after recent interest)
>> - VFS
>> - Weaver
>>
>> All other stuff can go dormant because there is currently nobody who
>> maintains it. Still a pretty long list. Thoughts? Anything missing?
>>
>> Benedikt
>>
>>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<de...@commons.apache.org>
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Re: [DISCUSS] Putting several unmaintained components to dormant
Posted by Adrian Crum <ad...@sandglass-software.com>.
What criteria are you using to come up with this list?
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 10/9/2013 12:17 PM, Benedikt Ritter wrote:
> Hi,
>
> I think Phil came up with the idea to try to focus on the components that
> we are able to maintain and put all other stuff to dormant. Here is the
> list of components that I think really are proper:
>
> - CLI
> - Codec
> - Collections
> - Compress
> - Configuration
> - CSV
> - Daemon
> - DBCP (?)
> - Email
> - Functor
> - Imaging (?)
> - IO
> - JCI
> - Lang
> - Logging
> - Math
> - Net
> - Pool (?)
> - Proxy
> - SCXML (after recent interest)
> - VFS
> - Weaver
>
> All other stuff can go dormant because there is currently nobody who
> maintains it. Still a pretty long list. Thoughts? Anything missing?
>
> Benedikt
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org