This sounds like a good plan. Thanks for being proactive on this.
It will be interesting to see what happens with the *new* lower
version. For exapmle, if the update sites that people use have both the
new and old with the new version being lower then users likely will not
be able to get the right thing. Would you see removing the older versions?
As for the graduation review, do you have a set of code that you would
like to release now? If that is true then you might just graduate with
a higher version number and remove the old versions.
I think that either option would be fine. Thanks again.
Jeff
Martin Lippert wrote:
Hi Jeff,
we discussed this briefly and the result is: we would like to do ALL
this stuff... ;-)
Our idea would be:
1. lower the version numbers to make the incubator status clear. This
includes communication with the community to avoid confusion and to
make clear that this does not include lowering the quality of the code
produced so far... ;-)
2. produce some more milestone builds instead of what we called
releases in the past. We will write up a project plan as a wiki page
that includes open bugs and our goals for upcoming milestone builds.
3. start the graduation process for a future first release of equinox
aspects including reviews, a release review and whatever is necessary
to graduate... :-)
What do you think?
-Martin
Jeff McAffer wrote:
Possible solutions:
- graduate
- lower the version numbers
In either case there will need to be a review if there is going to be
a "release". You could avoid a review if the version number is
lowered AND the event is rephrased as a milestone.
As for dealing with the past, well, dropping the version numbers
would certainly cause some confusion. Graduation would retain the
version number sequence but we'd have to have a discussion in the
wider community to see if graduation is warranted (I have no evidence
either way at this point).
I'm certainly open to alternatives.
Jeff
Martin Lippert wrote:
Thanks Bjorn and Jeff for the clarification!
Now the question arises how we should deal with upcoming releases of
equinox aspects while being in incubation... ;-)
Since we published releases with versions 1.x I am not sure what the
best way is to move on. We mentioned the incubation within the
bundle names and download zips (according to the guidelines I hope).
Should we go back to versions 0.x with the next releases (with some
explanations to avoid confusion)?
-Martin
Bjorn Freeman-Benson wrote:
The policy that we've been following/enforcing is that a project in
incubation must have releases < 1.0 and that projects out of
incubation have releases >= 1.0. I apologize that this is not
clearly written.
Jeff McAffer wrote:
In any event, Bjorn (cc'd) would certainly know if there is an
actual policy on this.
------------------------------------------------------------------------
_______________________________________________
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev