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

[David M Williams <david_williams@xxxxxxxxxx>]

> 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?

Sounds like it works, but sounds like overkill, to me
-- that is making extra work for yourselves. Maybe I'm tainted by what
I'm used to, so if it works for you, it can't be all that bad. 

First of all, sort of matching what you do, we do often
do "experimental" work in a branch, and then merge that in to
HEAD, once it gets far enough along to be considered viable. 

But I think most projects use HEAD as the most forward,
long term development (e.g. for next year). And its not that bad if an
occasional bug or regression is introduced, it can be caught in periodic
testing, before the code is formally released (that's partially why we
tell adopting products they should use only formally released builds in
their own releases ... not just any build, not even milestones).  Usually,
committers run unit tests, etc, locally before committing to HEAD, to have
some assurance their code is not causing regressions (but even then, unit
tests don't catch everything). This allows the easiest way to make progress
on new things, or large changes, with minimal fuss. 

We typically branch the code for maintenance, and then
we build only that maintenance branch for the maintenance release. That
way, the changes in the maintenance branch can be minimized to only the
fewest things really needed for maintenance. No new features (I see now
how your questions might be related  :) and no bug fixes which might
be considered "risky". No big reformatting of code, no NL changes,
etc. (well minimum NL changes).  In our project, we even discourage
"minor" fixes ... just to leave as much unchanged as possible
(though committers often can't stand some of those minor bugs, and fix
them anyway :) We also discourage changing any "public" or "protected"
method, even if not formally API, just because someone might be depending
on that "internal" code and we want to be a stable as possible
for adopters, especially for maintenance. Whereas for the next major release,
we more freely change "internal" code, with less worry, since
then there is as least time for an adopter to let us know if they really
really needed one of those internal things and time for us to work with
them on resolving. 

All this is made possible though the magic of using maps
files: our PDE based builds can fairly easily select "HEAD" map
files or "branch" map files as a whole. It is a level of redirection,
I suppose. In some subprojects, if all the work they do is for both maintenance
and the next major release, they just continue to use HEAD for their code,
and then "release" the exact same thing to both map files. But
when work for maintenance and work for next major release start to differ,
they also have to branch code. That has the complication that anything
that is done for maintenance has to also be merged into HEAD, which is
normally pretty easy, but can get complicated if the two branches differ
a great deal. 

Plus, we even sometimes have additional branches, such
as for "patch builds" ... for some off-cycle emergency ... not
for the feint of heart! :) 

We couldn't live with only one main stream ... it'd either
slow us down too much in HEAD, or make our maintenance too risky. But,
every project is different, has different styles, different needs, etc.,
so there's definitively not just one right way. It is interesting to hear
how others do things.

From:	Daniel Pastore <kpqb38@xxxxxxxxxxxx>
To:	Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
Date:	06/30/2010 12:23 PM
Subject:	[cross-project-issues-dev] Re: Adding features during service        releases and how/when to tag and branch source code ....
Sent by:	cross-project-issues-dev-bounces@xxxxxxxxxxx

---

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_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev