As Doug said, you could do a Minor release that conicides with SR1 for
Helios.
Dave
On 06/30/2010 11:25 AM, Doug Schaefer wrote:
Well, yes that's what I meant from the opposite angle. The
point is that you need to be clear to the community when new
functionality is included in a release, and hiding it in a service
release which usually does not contain new functionality, isn't
community friendly. So if you have new functionality, make it at least
a minor release and have a review. And, of course, you can do that any
time. Being on the train does not prohibit you from making additional
releases over the year.
On Wed, Jun 30, 2010 at 2:16 PM, Christian
W. Damus <give.a.damus@xxxxxxxxx>
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,
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>
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>
|
| To:
|
David M
Williams/Raleigh/IBM@IBMUS
|
| Cc:
|
Marcel Gorri <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
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
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
|
