Having trunk(2.0.x), 1.1.x, 1.2.x, and 1.0.x seems about right.
I don't particularly like adding branches and dual / triple
maintenance.
If anyone has a better idea I'm open to suggestions.
I think that we can create these branches lazily -- that is, I don't
think that we need to have both 1.2.x and 2.0.x if we aren't working
on things for 2.0 that would be disruptive for 1.2. I think that that
could help mitigate the branching overhead.
I was thinking of it as more
of an ongoing release manager role for the consumer that proposed the
release.
I think that we (BEA) definitely are in favor of a "branch manager"
sort of situation, in which the branch manager has additional
responsibilities.
-Patrick
On Apr 8, 2008, at 10:48 AM, Michael Dick wrote:
Minor edit below
On Tue, Apr 8, 2008 at 10:00 AM, Michael Dick <[EMAIL PROTECTED]>
wrote:
On Fri, Apr 4, 2008 at 2:22 PM, Patrick Linskey <[EMAIL PROTECTED]>
wrote:
Hi,
We (BEA) would like to get a 1.1.0 release underway so that we can
release off of the 1.1.x line for our upcoming WebLogic Server
release. Soooooo:
- Any objections to getting the process under way to make a 1.1.0
release?
No objections from me. We're probably about due for another trunk
release.
What sort of timeframe were you thinking? Would the end of April /
beginning
of May work for you?
- The first step is to do some JIRA issue triage work to figure out
what needs to be in 1.1.0 and what can be deferred. If you have
issues
you know of that you feel strongly about one way or another, now's
the
time to set the release information in JIRA appropriately.
Will do.
- We (BEA) will want to keep the 1.1.x branch to a minimal set of
critical changes; I think that we're a bit more conservative about
changes than what has happened in the 1.0.x branch so far. I'm
guessing that over time, different OpenJPA consumers will have
different needs in terms of branch lifecycles and update policies;
any
thoughts about how to codify this so that people know how
conservative
a particular branch should be?
I agree and I've been thinking about this a bit too. I think we need
another branch in the mix. Right now trunk contains the ongoing
code for the
next major release and minor release. As a result we've blurred the
lines
between the two (and it flowed over into 1.0.x as well). Having
trunk(2.0.x), 1.1.x, 1.2.x, and 1.0.x seems about right.
Then when a consumer proposes a release of OpenJPA they can also be
the
final arbiter of which fixes go into the corresponding branch. For
example
if BEA sponsors the 1.1.0 branch then the rest of us will play nice
and not
port fixes without approval. Other consumers can confine their
changes to
1.2.x, or trunk (as appropriate).
I don't particularly like adding branches and dual / triple
maintenance.
If anyone has a better idea I'm open to suggestions.
The original proposal might sound more draconian than I intended it
to be.
I'm not proposing a petition that *only* the party that proposed a
release
can make changes in the corresponding branch. I was thinking of it
as more
of an ongoing release manager role for the consumer that proposed the
release.
Also note consumers in this context should not be limited to the
organizations on the "powered by" page either, IIRC Geir was one of
the
leading advocates for the 1.0.2 release. In that respect he could be
considered a consumer (or sponsor which sounds a little nicer).
-Mike
-Mike
-Patrick
--
Patrick Linskey
202 669 5907
--
Patrick Linskey
202 669 5907
