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

[Daniel Pastore <kpqb38@xxxxxxxxxxxx>]

Hi David,

First of all, thanks for your prompt answer! :)

And yet regarding the version control policy, we just want to check if we are using a good policy.
Basically, what we do is:
- in the trunk (head) we keep the latest code, reviewed and tested (ensuring this way that the code is stable);

- for all bugs (fixes or improvements or new features), we first create a branch from the trunk, apply the patches and modifications of such bugs to this branch and then after reviewing and testing, we merge the code back to trunk.

Do you guys think this is a good approach? Is there any better approach you could recommend us?

> 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

-- 
Thanks,

Daniel Pastore