Skip to main content

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


> 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



Back to the top