Hi Jürgen, read inline...
Vincenzo
Jürgen Hoffmann wrote:
Hi Vincenzo,
reading your mail, I was wondering what the difference between a minor and a
major feature might be?
IMHO, in this context "minor" should mean simple and safe, or optional
(like a new mailet for example, whose usage is not mandatory at all).
Who sets the bar, who makes the decision?
*We* comitters should be wise enough to judge and make the decision
individually, and the commit can be withdrawed any time after a veto (or
simply after a short discussion on the list). We should just be not
touchy if it happens.
Who is
responsible to put the branch feature into trunk? IMHO it should be the other
way around.
- New Features into Trunk
- Bugfixes into the Release Branch of 2.3
- ported Features of Trunk that should be incorporated into the 2.3 codebase
should be done into a new branch with the name 2.4
That way everything is clean, everyone looking at the repository gets an idea
of how the project is structured.
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*.
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.
Question at hand is, how quick you want bugfixes to be released. If you
introduce features into the Release Branch, you maneuver yourself into a
one-way-street. You might introduce features that are not well-tested, and
that must be released with the critical bugfix that has to be fixed and
released.
I hope I was able to bring my point across...
Kind regards
Juergen
-----Ursprüngliche Nachricht-----
Von: Vincenzo Gianferrari Pini [mailto:[EMAIL PROTECTED]
Gesendet: Donnerstag, 21. Dezember 2006 10:48
An: James Developers List
Betreff: Re: [VOTE] Using of 2.3 branch
Norman Maurer wrote:
Hi all,
i start this vote because i want to get an idea what other developers
think about this. Here are the possible solutions:
1) Commit fixes and new "minor" features to 2.3 branch:
+1.
My point is: we need fixes plus minor features applied to code branch
that we can consider stable and safe, being used by most (I suppose)
people (the ones that have started to use 2.3.0). So let's try to do it,
with the goal of cutting a release quite soon, and limiting the new
minor features that we can consider really "minor".
When we cut it we vote on changing the name to 2.4.0 if there are *not
only* fixes (and I would vote +1 to such name change).
In other words, let's keep only one branch other than trunk and let's
work on both. And the current 2.3 branch is already "next-minor" (we may
already rename it for clarity).
The idea is that whatever goes into the 2.3/2.4/next-minor branch is
aimed to maximum stability and compatibility, and if something is not so
safe it *must* be optional and documented as such.
Moreover, I think that we are responsible enough to evaluate (the
unfortunately few of us that will do them) if a minor feature is really
low risk and could go into this branch, so I think that lazy consensus
is much better than voting every time. And for such minor stuff a road
map is bureaucracy. Next minor is
Finally, let's avoid religion wars around names :-) , and let's avoid
becoming like the Italian Parliament these days ;-) .
2) Commit only bugfixes to 2.3 branch:
-0
So please cast your votes and tell me what you prefer.
bye
Norman
Vincenzo
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
!EXCUBATOR:1,458a588344674840514886!
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
