[Nutch Wiki] Update of "Committer's Rules" by AndrzejBialecki

[Apache Wiki <wi...@apache.org>]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Nutch Wiki" for change notification.

The following page has been changed by AndrzejBialecki:
http://wiki.apache.org/nutch/Committer's_Rules

New page:
= Commits and Release Engineering =

Committers should follow these guidelines when deciding, which branch to use for committing the patches and when to commit.

== Branches and Release Engineering ==

1. The SVN repository consists of the following areas:

 a. '''trunk''' (equivalent to CVS HEAD), where the current development code base is found. This area is not always guaranteed to be in usable state, some occasional breakage may occur, some parts of the code base may not work properly or at all. This is the area for developers, the "bleeding edge", and usually not suitable for stable production - average users are discouraged to use it, unless they miss some functionality available only here, and are prepared to face some hardships (such as the lack of documentation, the issue of setting up a development environment, bugs, etc).

 a. '''Release-x.x''' branches, where the code from each release is put for further maintenance. These areas contain code, which is considered "stable", i.e. at the point of release it was known to be working well, ''within the limits of functionality available for that release''. The code here is also maintained in a well-working state for a certain period after release, but only minor fixes are applied here in order to provide a solid product with the functionality of the given release. Normally, no new functionality should be added to the maintenance branches. It is unacceptable to introduce changes to this branch, which would break the compatibility with the earlier code within the same branch.

 a. any other temporary branches (such as e.g. "mapred"), which serve as temporary repository for the work to be merged with the trunk at a later stage. You should not expect anything functional here, unless the developers explicitly ask for help in testing and integration.

2. The trunk is the area, where active current development occurs. New features and enhancements are first committed here.
 a. This requirement helps to minimize the risk of losing new features and enhancements somewhere on the branches, because as the time goes it is more and more difficult to forward-port them from the past branches to the trunk.

 a. If some changes are invasive and would result in prolonged periods of breakage, they probably need more development time before they are integrated with the trunk. If you want other developers to join you in work, it's a good idea to put these changes on a temporary branch to be merged later with the trunk.

3. If there are important features or fixes, which will benefit majority of users, these can be back-ported to release branches, after they have been committed to the trunk (if appropriate). The back-porting process should involve extensive testing to ensure that the code on the Release branch remains stable and production-quality. It is unacceptable to commit code, which breaks the build process, or is known to be unstable. Users will expect from the Release branches to be stable and working with production quality at all times.

== Backward compatibility ==

== Committer's checklist ==
Things to check before commit.

Re: [Nutch Wiki] Update of "Committer's Rules" by AndrzejBialecki

[Piotr Kosiorowski <pk...@gmail.com>]

Doug Cutting wrote:>
> Glancing at other Apache projects in subversion, I see that httpd uses 
> branch names like "2.2.x" and tag names like "2.2.4".  That's a little 
> cryptic.  I propose that we use branch names like "branch-2.4" and tag 
> names like "release-2.4.1".  What do folks think?
> 
+1
In fact I wanted to do it this way when I started to create a branch but 
as noone objected against "Release-X.Y" name for branch that was present 
in Release-HOWTO I prepared ealier (and have not thought it through) I 
decided to go with Release-HOWTO version to avoid confusion.
I can try to change things in next few days if others agree. I will also 
rollback errorneous commit in "tags" subdirectory.

Regards
Piotr

Re: [Nutch Wiki] Update of "Committer's Rules" by AndrzejBialecki

[Jérôme Charron <je...@gmail.com>]

> 
> Glancing at other Apache projects in subversion, I see that httpd uses
> branch names like "2.2.x" and tag names like "2.2.4". That's a little
> cryptic. I propose that we use branch names like "branch-2.4" and tag
> names like "release-2.4.1". What do folks think?

+1

Jérôme

-- 
http://motrech.free.fr/
http://www.frutch.org/

Re: [Nutch Wiki] Update of "Committer's Rules" by AndrzejBialecki

[og...@yahoo.com]

> Glancing at other Apache projects in subversion, I see that httpd
> uses 
> branch names like "2.2.x" and tag names like "2.2.4".  That's a
> little 
> cryptic.  I propose that we use branch names like "branch-2.4" and
> tag 
> names like "release-2.4.1".  What do folks think?

I agree.  That is the convention I use in other projects, and it has
worked well.

Otis

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Simpy -- http://www.simpy.com/ -- Find it. Tag it. Share it.

Re: [Nutch Wiki] Update of "Committer's Rules" by AndrzejBialecki

[Doug Cutting <cu...@nutch.org>]

Apache Wiki wrote:
> 1. The SVN repository consists of the following areas:
> 
>  a. '''trunk''' [ ... ]
>  a. '''Release-x.x''' branches [ ... ]

This should also mention tags, fixed versions of the code where no 
development occurs.

I also would prefer that tag names and branch names are distinct, to 
decrease confusion.  In particular I do not like the word "Release" in a 
branch name, since that implies it is a released version.  I think only 
tags should be called releases.

Glancing at other Apache projects in subversion, I see that httpd uses 
branch names like "2.2.x" and tag names like "2.2.4".  That's a little 
cryptic.  I propose that we use branch names like "branch-2.4" and tag 
names like "release-2.4.1".  What do folks think?

Doug