On 11/26/2015 09:29 AM, Harald Oehlmann wrote:
Am 25.11.2015 um 22:08 schrieb Massimo Manghi:
I have a proposal for adopting this release numbers scheme
* I propose to prepare a 2.2.4 release simply removing the calls to
Tcl_DeleteInterp from src/apache-2/mod_rivet.c in order to fix the
occasional crashes during the child process termination
* code in branches/2.2 should become branches/2.3, as I did quite a few
additions and also I changed the module initialization stage (it was
once declared that this would have marked a minor version number bump).
This new code deserves closer scrutiny and a longer testing time before
releasing
* Code in trunk should become Rivet 3.0.0, as the core module was
radically changed
Moreover, while branches/2.2 could be safely copied as branches/2.3 I
would like to bring it back to the status it had on Sep 9th when the
commit removing Tcl_DeleteInterp was carried out. Any other solution in
order to attain this set up is welcome
Sounds good, thank you for the work!
Harald
I'm thinking of the best way to have a new 2.2 branch the way I want it
to be.
I created a diff file with the patches between tags/2.2.3 (r1680965) and
r1702115 committed on Sep 9th. We could copy that tagged revision as
branches/2.2 (after the current branch is renamed as branches/2.3) and
apply the patch but the whole history after Sep 9th would disappear from
branches/2.2 (it will survive in branches/2.3). I found also this
command suggested by a svn wizard
svn merge $(REPO)@$(GOODREV) $(WC)
that would preserve the whole history
what do you think Harald?
-- Massimo
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
