james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: AW: [VOTE] Using of 2.3 branch
Date Thu, 21 Dec 2006 16:27:25 GMT
Vincenzo Gianferrari Pini wrote:
> Agree, but at the same time having three branches is hard to mantain (we 
> know that from the past history of James), so what I think is worth is 
> to all of us be more *flexible and pragmatic*.

Imho mantainability depends on how much people is committed to the 
process of a given release. If we had 100 committers I would have no 
problems in having 10 branches.

Imho the problem in this thread is the mixed issue of the v2.3 branch 
and a release created starting from the v2.3 branch.

If I understood Norman's intentions for calling this vote, it is not 
about next-minor, but simply about the use of the "v2.3" branch we have 
in the repository.

When I vote -1 to use "v2.3" for new features I mean that I don't want 
that branch to be used for features, but I'm not against the creation of 
a release based on the v2.3 branch. I simply think that this deserve a 
PROPOSAL (concrete, with issues to be backported list) and a custom 
branch. Maybe that we'll never use the v2.3 for another release, but I 
don't think why to reuse branch names on svn. It seems to me simply 
following good practice.

> For example, I have in mind (and have a personal need) to put inside the 
> appropriate places of RemoteDelivery calls to two empty (just returning) 
> protected methods called onSuccess and onError (or some similar name), 
> to be able to build my own  personal extension "MyRemoteDelivery" 
> (inside a jar in SAR-INF/lib) that would log into an application 
> database the outcome of the delivery. I need and want to use 2.3.1 or 
> 2.4.n. The featrue is very "minor", in the sense that the code change is 
> very simple and safe. But I have not yet done it because I don't know 
> where to put it, so I may end up writing my own modified RemoteDelivery 
> mailet instead of using the official one plus my extension.

You should do this in trunk. Trunk is where development is done. After 
you have done this in trunk we can discuss wether to backport it to some 

This is why backporting can be done with a vote after a proposal 
including the list of intended backports is done. As I said I prefer RTC 
for the v2.3 branch, but I'm not against using CTR: I thought that 
people that loose time working on that code would be happy to know ASAP 
if I will vote -1 to a release including what they just backported. Of 
course a single -1 will not block the release, but a majority of -1 will 
do, so it is better to understand each others and define the roadmap.

My concern with backporting features is that a LOT of bugfixes (either 
minor or major) have been done in trunk, and I think that selectively 
backporting all the bugfixes is already a really big task wrt a point 
release. I wouldn't like to make a release with backport of minor new 
features but not backports for bugfixes we did.


To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message