Hi Luc.
>
> I have had several questions about release plans for 3.0.
>
> I feel guilty for not having pushed this version out yet.
"Release early, release often ..." would alleviate this feeling.
And would reduce the tensions here because much less *new* things would be
under discussion between releases, because much less new bugs and new
features accumulate, thus further delaying the next release.
Please, don't take this as a rant; I don't want this thread to become
another endless and useless discussion. But it is a fact that the current
release policy is obscure: E.g. the last release has been "self-serving"
without regards to the implications on the mid-term agenda (i.e. the
long-overdue release of 3.0)
Again, don't take it personally; I think that the problem is related to the
a so-called "user-centric" development model, in a context where we rarely
see those users who are not developers.
In the absence of "users-only", the CM developers should, IMHO, foremost be
working towards making releases that reflect the changing state of the
library. We could define some metrics that objectively characterize the
development flux[1]; when some threshol is reached, we *must* start to
prepare a release, freezing the development and having everyone
concentrating on issues that block that new release.
> It is not in
> release shape now and many thing are still ongoing.
Yes, despite several commitments that new features should be deferred to
after 3.0.
> Typically, a new
> thread as been started a few hours ago about an important change in the
> linear algebra API (a needed change, so something important to discuss now).
I agree that it would be nice to fix this issue. But I note that it is not
*required* to be done before releasing 3.0.
Many things will surely to need breaking updates fairly soon, and it
shouldn't be considered harmful to assume that 4.0 could come relatively
soon after 3.0. IMO, more than 2 years for a new major release belies the
actual work that has been performed.[2]
> As far as I am concerned, here are the points I want to address myself
> (but if other people want to help, chime in!). I would like to see what
> other developers have in mind so wa can set up a release plan, and
> really work toward a release which is past due.
>
> My personal tasks are:
> - finish the adapters wrapping unbounded optimizers into simple bounds
> optimizers as set up by Gilles, using the two function adapters
> already available
> - stabilize Adams based ODE integrators using the
> MathUtils.linearCombination feature to ensure better accuracy and
> error estimates in the Nordsieck vectors
> - perhaps add back the BDF integrator for stiff problems, using the
> Nordsieck vectors once it has been stabilized for Adams methods
> - perhaps add a Radau integrator
> - replace the reset() method in step handler interface by init()
> (it's a simple rename), and add a similar init() in the events
> interface
> - fix the mapping between boundary representation/BSP representation
> in 2D/3D
It's not polite to tell other people what to work on, but please forgive me:
Are those issues *blocking*? I suspect that everything that starts with "Add
..." is not. Even some improvements that are foreseen could wait for 3.x.
Part of the policy should be to refrain from wanting "everything, now". In
fact, I'm pretty sure that by releasing often, we'll be able to offer more
features in less time.
> could other people add to this list the features they want to have in 3.0 ?
I think that more important is the review of opened tickets, asking for
people to commit working on them... [Oops, sorry again.]
Best regards,
Gilles
[1] Based on the number of commits, number of opened and resolved issues,
and so on. [Please add your preferred criteria.]
[2] And the side-effect is that it makes it difficult for "users-only" to
actually have a say on individual design changes, as the more time
passes, the more difficult it will be to reverse a change thay may have
become intertwined with later ones.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
