We now have three staging branches. These are:
2.3-staging
2.2.1-staging
2.2.2-staging
2.3-staging can be treated as master usually is: It is for development
on what will become 2.3 and is now open for commits. This branch will be
merged into master after the release of 2.2.0.
The 2.2.x-staging branches should be treated as 2.2.x usually is: They
are open for commits to what will become the 2.2.x branch. The
difference, obviously, is that 2.2.1-staging is for commits that will
become part of 2.2.1; 2.2.2-staging is for commits that may not become
part of 2.2.1 but will eventually go to 2.2.x. So commits to either of
these branches need my approval.
At the moment, the plan is to reserve 2.2.1 for a fairly quick
bug-fixing release in response to problems that arise after the release
of 2.2.0. However, there are other sorts of "very safe" patches that
could go to 2.2.1---an example would be JMarc's patch moving the
documentation change logs---so I want to have this branch at least
available to keep track of them.
For the most part, then, fixes intended for 2.2.x that are now too late
for 2.2.0 should go to 2.2.2-staging. If things go really, really
smoothly, some of these might be good for 2.2.1.
The 2.2.1-staging branch will be merged into 2.2.x once that has been
branched from master. The 2.3-staging branch will be merged into master
once 2.2.0 is released.
We do not yet have an agreed policy for how fixes should be marked in
trac. I'll make a proposal in another thread.
Richard
