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 <joerg.schai...@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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
