Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Adding features during service releases and how/when to tag and branch source code ....

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



Back to the top