Stefano Bagnara wrote:
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.
True.
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.
True.
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 branch.
And I will do it that way. But then I need to immediately backport to
2.3 (or 2.4), because I have to deliver it to a Client with my extension
(I'm using this as an example, but is real :-) ).
For me it's all the same: the only difference is that if we have 2.3,
2.4 and trunk we have to backport twice any fix. But let's then create a
2.4 branch.
FWIW, there is a missing functionality in SVN compared to SourceSafe:
the *share/split* concept. It would allow a much easier common
management of two very similar branches as 2.3 and 2.4 would be. When I
talked about that to the SVN people in ApacheCon Europe, they simply
didn't know it and then said that it's a matter of habit, but it's not
true. Anyway this is not pertinent to James... :-)
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.
What are RTC and CTR :-) ?
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.
Stefano
Vincenzo
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
