Re: [cross-project-issues-dev] Adding features during service releases

[Doug Schaefer <cdtdoug@xxxxxxxxx>]

A question came up the other day on the cdt-dev list. Can different
components managed by a project have their own releases, or is it an
all or nothing deal. I don't remember seeing a component release
review.

On Wed, Jun 30, 2010 at 4:03 PM, Wayne Beaton <wayne@xxxxxxxxxxx> wrote:
> Section 4.6 states:
>
> "Bug fix releases (x.y.z, e.g., 2.3.1) with no new features over the base
> release (e.g., 2.3) are allowed to be released without an additional Release
> Review. If a bug fix release contains new features, then the Project must
> have a full Release Review."
>
> As Doug says... it's all about involving the community.
>
> Wayne
>
>
> Christian W. Damus wrote:
>>
>> Hi, Doug,
>>
>> The EDP doesn't say that service releases can't include new function
>> because that would require a review.  IIUC, it says only that adding new
>> function in a release requires a review, and that service releases are
>> (usually) exempt from review because they (usually) don't deliver new
>> function.
>>
>> So, I suppose that if a service release really needs new function, the
>> project can schedule a release review.  If that passes (guess what might be
>> an objection :-) then the project can publish the release.
>>
>> Cheers,
>>
>> Christian
>>
>>
>>
>> On 2010-06-30, at 13:27, Doug Schaefer <cdtdoug@xxxxxxxxx
>> <mailto:cdtdoug@xxxxxxxxx>> wrote:
>>
>>> I wonder if a "new feature", as in new functionality, would trigger the
>>> need for a release review and, thus, couldn't be done in a service release.
>>> yes, no, maybe?
>>>
>>> On Wed, Jun 30, 2010 at 11:22 AM, David M Williams
>>> <david_williams@xxxxxxxxxx <mailto:david_williams@xxxxxxxxxx>> wrote:
>>>
>>>
>>>    Daniel, I've replied on "cross-project" list.  Hope you don't
>>>    mind .... but, I do so since
>>>    1) others probably have the same questions and they would like to
>>>    know the answers too, and
>>>    2) others probably have much better answers than I do! :)
>>>
>>>    > 1) Is it ok to release new features on a Service Release? Or
>>>    should they go just on the next major version?
>>>
>>>    I'm assuming you mean literally a new feature, in the sense of an
>>>    installable feature that has its own feature.xml. But, even if
>>>    you mean merely new function, in an existing feature.xml, the
>>>    answer is pretty much the same.
>>>    It is sort of discouraged, just because
>>>    a) its can be tricky to do, and have everything "update"
>>>    correctly (but it is possible),
>>>    b) depending on what it is, it can kind of surprise adopters,
>>>    maybe effect additions they have added themselves, or perhaps
>>>    effect tutorials, or translations they have done.
>>>
>>>    But, first and foremost, it depends on what your project (and
>>>    your adopters need). If you (or your adopters) need it, it can
>>>    and should happen. You'd want to review with your project leads,
>>>    mentors, and PMC and make sure all agree its important and
>>>    reasonable, and its being added in the best possible way ... such
>>>    as, is it a new feature that gets added automatically ... is it a
>>>    feature that adopters/users can install "optionally"?  Also, in
>>>    some cases maybe it should just to in your own projects software
>>>    repository, but not complicate the common repository, but in
>>>    other cases, maybe it is critical to add to the common
>>>    repository.  After PMC discussions, you'd probably want to well
>>>    notify the community on these new plans ... both your own, on
>>>    your own specific newsgroups and mailing lists, but also the
>>>    cross-project list just so others know what's changing in common
>>>    repo, and can offer advice, or concerns, if there is any concerns
>>>    (and probably would not be concerns, for 99% of the cases).
>>>
>>>    > 2) Is there a standard on source code policies (branching
>>>    versioning, etc) for Eclipse projects?
>>>
>>>    Definitely not a standard, per se (well, I'm assuming you are not
>>>    talking about the versioning of bundles, which is standard, and
>>>    documented in http://wiki.eclipse.org/Version_Numbering).
>>>    But most projects do have their own project-wide practices, and
>>>    some projects have tried to document how they tag code once
>>>    released, and how and when they branch map files and code. Such
>>>    as WTP has the following document, but I know its kind of sloppy
>>>    (which I can say, because I wrote it, and recently fixed some
>>>    extremely out of date sections, but its been "hack edited" so
>>>    many times, its ended up kind of sloppy and maybe incomplete),
>>>    http://wiki.eclipse.org/WTP_How_to:_Branching_Policy_and_Practices
>>>    Perhaps other projects have their own documents on how and when
>>>    to tag and branch source code and could contribute them to this
>>>    discussion?
>>>
>>>    Thanks ... and keep the questions coming ... we all learn in Open
>>>    Development, when people ask questions -- either directly, or
>>>    even for us answering, provides a good opportunity to stop and
>>>    think "how do we do that and why do we do it that way?"
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>    From:       Daniel Pastore <kpqb38@xxxxxxxxxxxx
>>>    <mailto:kpqb38@xxxxxxxxxxxx>>
>>>    To:         David M Williams/Raleigh/IBM@IBMUS
>>>    Cc:         Marcel Gorri <wmg040@xxxxxxxxxxxx
>>> <mailto:wmg040@xxxxxxxxxxxx>>
>>>    Date:       06/30/2010 09:12 AM
>>>    Subject:    Can you help us with some questions?
>>>
>>>
>>>
>>>  ------------------------------------------------------------------------
>>>
>>>
>>>
>>>    Hi David,
>>>
>>>    we would like to ask you (as a great expert on the Eclipse way of
>>>    doing things) two questions we have:
>>>    1) Is it ok to release new features on a Service Release? Or
>>>    should they go just on the next major version?
>>>    2) Is there a standard on source code policies (branching,
>>>    versioning, etc) for Eclipse projects?
>>>
>>>    --     Thanks a lot for your patience :)
>>>
>>>    Daniel Pastore
>>>
>>>
>>>    _______________________________________________
>>>    cross-project-issues-dev mailing list
>>>    cross-project-issues-dev@xxxxxxxxxxx
>>>    <mailto:cross-project-issues-dev@xxxxxxxxxxx>
>>>    https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>>
>>>
>>> _______________________________________________
>>> cross-project-issues-dev mailing list
>>> cross-project-issues-dev@xxxxxxxxxxx
>>> <mailto:cross-project-issues-dev@xxxxxxxxxxx>
>>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>
>
> --
> Wayne Beaton, The Eclipse Foundation
> http://www.eclipse.org
>
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>