Community
Participate
Working Groups
I'm not even sure that I think this is a worthwhile effort, but felt obligated to open this bug for discussion. With current EDP, only _projects_ can have an official Eclipse _release_. But they do not need to be "graduated" or "1.0 releases" .. they can still release even if they are a stand alone incubating subproject. But, at times, there are _components_ of incubating projects that want to "release", before they are ready to graduate, be in their own project, or move to another project. For example, see discussions around http://dev.eclipse.org/mhonarc/lists/wtp-pmc/msg01742.html The main "need" to have this type of a release is that an adopter project or product wants to use it in its own release, so they would like the reassurance that it is IP clean, and will have at least some persistent life, at least in the form of a distributable build; even if it later poops out and does not graduate. I'm sure there's pro's and con's. We can certainly encourage components such as these to go ahead and graduate, move, or make their own sub-project .. and lots of goodness in that ... but if they are not really ready to graduate, exactly, and, say, simply become an incubating standalone sub project, then there is some risk this would have the side effect of causing more work for everyone later on, if they need to move again or re-organize say 6 months later. So, again, not sure it is frequent enough to change the EDP, but it does seem kind of heavy weight to say some components have to be a "project", just to say they are IP Clean ... but, maybe that is the only practical way to track things to do the bookkeeping required to say they are IP clean. So, just opening this for discussion, to see if it comes up often. I do not see it as a serious "blocking progress" sort of issue. Just a "degree of work" issue ... and not sure how that balances out. I would, by the way, say it is fair and good that once something is a graduated and at least a 1.0 project that is does have to release all-or-nothing style ... since that could have odd implications for adopters who are using those "projects" if suddenly some small part of it changed "in the wild". But with pre-1.0 components, I think it is understood by adopters there is some stability risks there ... and while they may accept that risk, they would still want to make sure it is considered IP clean and have at least some persistent life.
(In reply to comment #0) > I would, by the way, say it is fair and good that once something is a graduated > and at least a 1.0 project that is does have to release all-or-nothing style > ... since that could have odd implications for adopters who are using those > "projects" if suddenly some small part of it changed "in the wild". But with > pre-1.0 components, I think it is understood by adopters there is some > stability risks there ... and while they may accept that risk, they would still > want to make sure it is considered IP clean and have at least some persistent > life. The most recent version of the EDP removes the "all or nothing" nature of releases. You can release a subset of the code.
I that, more generally, we are talking about the ability for a project to make individual releases of subsets ("components") of their overall functionality. It seems natural enough to do this in an incubator, but is there any reason to restrict it to incubators? Does it make sense for a mature-phase project to release "functional bit A" 1.0 and "functional bit B" 1.9? I suspect that this can lead--ultimately--to confusion. But is this something that the project can decide for itself? i.e. should we let the project decide whether or not this makes sense for their community? It would make it hard to talk about "Project A version x", but does that matter?
> > The most recent version of the EDP removes the "all or nothing" nature of > releases. You can release a subset of the code. Wait ... what? Isn't that a component? I'm confused. Or, maybe you mean subset, as long as that subset is also a subproject?
(In reply to comment #2) > I that, more generally, we are talking about the ability for a project to make > individual releases of subsets ("components") of their overall functionality. > It seems natural enough to do this in an incubator, but is there any reason to > restrict it to incubators? Does it make sense for a mature-phase project to > release "functional bit A" 1.0 and "functional bit B" 1.9? > > I suspect that this can lead--ultimately--to confusion. But is this something > that the project can decide for itself? i.e. should we let the project decide > whether or not this makes sense for their community? > > It would make it hard to talk about "Project A version x", but does that > matter? Well, I guess you are right. I was just trying to be orderly and match existing "use cases" I know about to the EDP rules. But, I could imagine a example case where, say, the Source Editing subproject in WTP wanted to "release" a new version of a CSS Feature (editors/tools) but not the rest of the editor/tools in Source Editing. (The rest not being ready, or not having changed). I've always thought if a mature project wanted to do that, they essentially could, and they could simply say "oh, by the way, the only thing that's changed in this release is the CSS Editor, the rest is the same". Whereas the WTP Incubating project doesn't have that option, since they never do a "complete release". So, I see how your suggestion is essentially the same as having a release where some stuff has changed an some stuff hasn't. So, I agree, unless required for order or book keeping, I see no reason to force the issue.
(In reply to comment #3) > > > > The most recent version of the EDP removes the "all or nothing" nature of > > releases. You can release a subset of the code. > > Wait ... what? Isn't that a component? I'm confused. Or, maybe you mean subset, > as long as that subset is also a subproject? The previous version of the EDP essentially stated that you must, as part of a release, include bits from _all_ the source code in your VCS. I removed that with the latest. Your release can now exclude some bits of the code. A project might, for example, have some functionality that they're working on, but are not quite ready to release when the time comes. You couldn't (strictly speaking) do that before.
I would like to add some more words to what David says in his initial comment. There are cases where the component, contributed to an Incubator, is mature code. And, as David mentioned in another discussion, the reason for this code to be in the Incubator, is for the contributing developers to learn the Eclipse Way of open development. After this is achieved, then the component is moved out of the Incubator to the respective project. Well, to achieve the goal of _open development_, all work on this code is moved out of the contributing company's infrastructure to the Eclipse Incubator's infrastructure. This way if the contributing company wants to consume this code in some latest product, then it needs to adopt it as _released_ binaries. It doesn't really matter if this binaries are project or component.
(In reply to comment #6) > I would like to add some more words to what David says in his initial comment. > > There are cases where the component, contributed to an Incubator, is mature > code. And, as David mentioned in another discussion, the reason for this code > to be in the Incubator, is for the contributing developers to learn the Eclipse > Way of open development. After this is achieved, then the component is moved > out of the Incubator to the respective project. > > Well, to achieve the goal of _open development_, all work on this code is moved > out of the contributing company's infrastructure to the Eclipse Incubator's > infrastructure. This way if the contributing company wants to consume this code > in some latest product, then it needs to adopt it as _released_ binaries. It > doesn't really matter if this binaries are project or component. Frankly, I'm surprised. I would think that a company would be hesitant to consume code for an actual product from an incubator. Incubators are by their very nature unstable. Like other projects, incubators have a single group of committers who all have equal access to all resources owned by the incubator. Imagine a scenario where a well meaning new committer-in-training for some other aspect of the incubator starts hacking at your component. IMHO, incubators are a good place to try out ideas, but once those ideas start to take on a real identity of their own (and are consumed by real products), it's time for them to move to either an existing project or a new one.
Assiging to AC for their input.
I believe that this is a duplicate of Bug 345755. If there's a subtlety that I'm missing, please reopen. *** This bug has been marked as a duplicate of bug 345755 ***
