Bugzilla – Full Text Bug Listing
| Summary: | [EDP] Eliminate the pre-1.0 versioning requirement for incubating projects | ||
|---|---|---|---|
| Product: | Community | Reporter: | Konstantin Komissarchik <konstantin> |
| Component: | Architecture Council | Assignee: | Eclipse Management Organization <emo> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | Achim.Loerke, caniszczyk, contact, david_williams, eclipse.org-architecture-council, Ed.Merks, gunnar, mknauer, stepper, wayne.beaton |
| Version: | unspecified | ||
| Target Milestone: | 2013-Q4 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 367236 | ||
|
Description
Konstantin Komissarchik
A case where this would have helped: http://dev.eclipse.org/mhonarc/lists/technology-pmc/msg03159.html (In reply to comment #1) > A case where this would have helped: > http://dev.eclipse.org/mhonarc/lists/technology-pmc/msg03159.html You're right. This would have solved the "0.x versions are viewed as crap" problem. Since we're concerned I'll take this bug to the Architecture Council for discussion. I always thought it was guideline, than an absolute requirement. The sort of thing a PMC should "approve with good reason" ... allow when seems reasonable, but disallow if an brand-new just-getting started project wants to jump to "4.1" simply to give some marketing appearance? Of course, I'm one to assume all rules have exceptions :) ... so, not saying some documented process couldn't be improved. (In reply to comment #3) > I always thought it was guideline, than an absolute requirement. It's actually in the EDP, section 4.2 "Any Project in the Mature Phase may make a Release. A Project in the Incubation Phase with two Mentors may make a pre-1.0 Release. A Release may include the code from any subset of the Project's descendants." I suppose that we could argue that the wording leaves some wiggle room, but the spirit of the rule is that the incubating projects only do pre-1.0 releases. Of course, there are also some guidelines regarding incubating branding that are problematic. http://wiki.eclipse.org/Development_Resources/HOWTO/Conforming_Incubation_Branding Reassigning to AC for their consideration. *** This bug has been marked as a duplicate of bug 330 *** Oops. The Window Builder has this issue, but they simply did a 1.0 release quickly, just 5 months after creation. Doing at least one "incubation release" as part of the incubation process doesn't seem such a great burden and is a good way to learn all the steps in the process so that future releases go smoothly. Projects should have an incubation phase and projects should do releases in an incubation phase. However, requiring projects like WindowBuilder, Jubula and Hudson to do a 0.x release just because they are in incubation sounds counter-productive to me. Hudson is a good example IMHO. They did a 2.x release before moving to Eclipse. Now they are incubating at Eclipse. What should be the next release number? I think a top-level PMC should be able to discuss this issue and make an exception to the 0.x requirement on a case-by-case basis. Completely agree with Gunnar. An exception should be made for projects that have had previous releases prior to joining Eclipse. Incubation is as much about the community building process of a new project. A mature code base might have an immature contributor community and therefore need that incubation period to get their open source processes in place. I think of a release version number as mostly a statement of the code's maturity, and needs to be aligned with expectations of any pre-existing consumer community (first release at eclipse having a larger version than last release prior to joining). (In reply to comment #8) > The Window Builder has this issue, but they simply did a 1.0 release quickly, > just 5 months after creation. Doing at least one "incubation release" as part > of the incubation process doesn't seem such a great burden and is a good way to > learn all the steps in the process so that future releases go smoothly. We've done this sort of thing with a couple of projects. They do a quiet incubation release shortly after they've got all their IP cleared, their build in place, and a little experience with the EDP. As Ed states, the idea is to develop familiarity with our processes (incubation is as much about learning the EDP, developing community, etc. as it is about maturity of the code base). The incubation release is quiet, intended primarily for the committer and adopter communities to avoid confusing the user community. In many cases the second release coincides with graduation and a continuation of the previously-established version numbering scheme. I think this sort of practice is a good thing, but agree that there are exceptions. I'd like to try and close the loop on this bug. I think that our current solution works. The general rule is that projects in incubation must do <1.0 releases. We have made exceptions to this rule. In some cases the exception has been as I suggested: one "quiet" incubation release followed by a more public graduation release. In other cases, we have allowed incubating projects to do a >1.0 release because it was the right thing to do to serve the project and the community. Maybe that's what we need to do... add a bit in the EDP that states that, from time-to-time the EMO will grant and exception in cases where an alternative to the stated rules is the right thing to do to serve the project and community. (In reply to comment #12) > Maybe that's what we need to do... add a bit in the EDP that states that, > from time-to-time the EMO will grant and exception in cases where an > alternative to the stated rules is the right thing to do to serve the > project and community. +1 Absent a clear need, I believe we should favor letting the projects operate in the manner that makes the most sense for them and their communities. So, what need is served by having the 0.x version requirement for incubating projects? EDP already requires the egg graphic on the project's website and "incubating" verbage on feature names, bundle names, zips, etc. I think we can safely say that we are calling sufficient attention to project's incubating status. Is re-enforcing the incubating/mature distinction via versions really necessary any more? It seems that the need isn't critical if we are willing to have an exception process, so why not leave the decision completely in the hands of the project? Perhaps this should become a recommendation rather than a rule. How about we change this: -- Any Project in the Mature Phase may make a Release. A Project in the Incubation Phase with two Mentors may make a pre-1.0 Release. A Release may include the code from any subset of the Project's descendants. -- to this: -- Any Project may make a Release, regardless of phase. * A Release may include the code from any subset of the Project's Sub-Projects; * Releases made by projects in the incubation phase must be clearly labeled as "incubation releases"; and * Perpetual "Incubator Projects" do not create releases -- This is still too wordy. Perpetual incubators don't do releases. Everybody else can. The EDP makes no requirement of how releases are named. The distinction between an "Incubator Project" and a "project in incubation" is a little too subtle for some. *** Bug 330729 has been marked as a duplicate of this bug. *** How about this (based on the principle that that you don't forbid is permitted, so no need to mention subsets): Any Project, with exception of perpetual incubators, may make a Release. A Release made by a project in the incubation phase must be clearly labeled [1]. [1] technical details on the labeling requirements... (In reply to comment #17) > Any Project, with exception of perpetual incubators, may make a Release. A > Release made by a project in the incubation phase must be clearly labeled > [1]. We're getting there. The footnote should say something about requiring incubation branding and defined by the EMO. We can include a "comment" link pointing to the incubation branding requirements. FWIW, we don't use footnotes anywhere else in the document, so we should probably just work this into the text. I'd like to move this paragraph to the 6.4 "Releases" and rename section 4.2 "Code and Resources". The releases discussion is out of place here. See Bug 419616. Just a thought that comes from a different perspective: A project that has been developed somewhere to a stage where it has mature >=1.0.0 APIs might already use API Tools. Because API Tools apply specific semantics to the major and minor version numbers that would mean that they can no longer be used if the project must decrease the bundle versions under 1.0.0. Personally I would find that unacceptable and decide not to contribute. Eike, shouldn't package names of a project change to org.eclipse.foo when moving to Eclipse? Good point! I was probably blind to this good argument because ten years ago I started the development of CDO outside of Eclipse, but with the right namespaces already ;-) I've changed it to: -- Any project, with exception of perpetual incubators, may make a release. -- And have included a paragraph later in the section to indicate: -- Releases for projects in the incubation phase must be labeled to indicate the incubation status of the project. -- This effectively eliminates the pre 1.0 requirement for incubation projects. Are we sure that we want to do this? I'm declaring victory. Marking FIXED. |