> On Wed, 12 Oct 2016 16:57:03 +0200, Emmanuel Bourg wrote:
>> Le 12/10/2016 à 16:15, Gilles a écrit :
>>> The 3.x line is obsolete.
>>> No new feature or bug-fix should be introduced there.
>> Hi Gilles,
>> I understand you don't want to invest time in maintaining the 3.x
>> and I respect that, but others might be interested. I don't think
>> pushing minor bug fixes to CM 3 will undermine CM 4.
> Work on 3.X did undermine CM4.
> [The problem here is that you want me to be synthetic, but you
> seem to have no clue about the history, thereby forcing me to
> recollect facts from the past, because you don't believe my
> synthetic statement above.]
> So, what you say in substance is that you'd rather _wait_ for
> someone to come by who will want to work with you on 3.x, rather
> than continue with people, here and now, a work (CM4) that
> started more than 3 years ago.
No, that's not what Emmanuel said, that's what you have implied. Your plan
is still valid to extract parts of the code base into own smaller
components. Once that components are created, we can deprecate the extracted
code in the CM3 code base and have a release. That's what we should do for
our existing users.
You made it very clear that you have no intention to put any additional
effort into CM3. Fine. And most of us will agree that CM4 is dead. But that
does not prevent any other committer from maintaining the CM3 line i.e.
applying bug fixes or small improvements as long as binary compatibility is
> There is no sufficient manpower to work on both (cf. the backlog
> of issues). [There wasn't before, and the situation did not
> improve after the fork.]
Obviously some work was done.
> It will be a waste for everyone if we split the already scarce
> resources to work on the two lines, of which the 3.x line will
> always be a "sub-Hipparchus".
Noone wastes *your* time ;-)
> In some areas/packages, code in the CM4 is still the same as
> in 3.x. And there is no one left in Commons that would want
> to significantly modify those areas, for which I have no qualms
> if you maintain them in 3.x.
> In areas where major changes were introduced in the development
> branch, my proposal is still that we try to split them off CM
> (see rationale in my posts sent in May).
> Commits should be done either in the 3.x line or in master, but
> not both.
This depends on the fact what code base you intent to extract for a new
component. Fixing code that exists in CM3 as well as in CM4 and that is
target for a new component is IMHO completely valid as long as the new
component does not yet exist. It is not clear in any case whether your
intention is to extract the code from CM3 or CM4, but after all it should
contain the bug fix.
> Can we agree on a list of legacy packages (maintained in 3.x),
> and a list of actively modified ones (worked on in master, in
> view of releasing them as independent tools)?
This list is obvious when all extracted code is marked as deprecated.
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org