To the release manager: Setting HEAD to 1.35 possible?

Would it be possible to already set the HEAD to version 1.35? Once the branch for release of a version has been made the head automatically should target the next number. Or I am missing something? Perhaps I am misunderstanding the general policy. What is the rationale for having HEAD and the latest branch for release pointing to the same version? Having different numbers would make it more comfortable having the development and release candidates in the same (install) place. Regards, Roland

Roland Schwarz <roland.schwarz@chello.at> writes:
Would it be possible to already set the HEAD to version 1.35?
Once the branch for release of a version has been made the head automatically should target the next number. Or I am missing something?
Perhaps I am misunderstanding the general policy. What is the rationale for having HEAD and the latest branch for release pointing to the same version?
Having different numbers would make it more comfortable having the development and release candidates in the same (install) place.
Sounds like a good idea to me. -- Dave Abrahams Boost Consulting www.boost-consulting.com

Thomas Witt wrote:
Roland Schwarz wrote:
Would it be possible to already set the HEAD to version 1.35?
That's fine by me. Please go ahead.
I assume it's sufficient to perform the steps that are outlined in the release managers checklist as # Verify the root/index.htm, root/boost/version.hpp, and root/Jamrules # release numbers are correct and agree. But replace "Verify" with "Change". Correct? I have also seen that usually the release manager of the upcoming release was changing this number, I assume during the "Verify". The current duties of the release manager include: # Tag the main trunk merged_to_RC_n_n_n. # Branch the main trunk with the tag RC_n_n_n Do you think it would be possible to add the following # On the main trunk: # Update the root/index.htm, root/boost/version.hpp and root/Jamrules # release numbers to n_(n+1)_0 to the duties of release manager for n_n_n ? As you have been suggesting, I will do this on the main trunk for now. Shall I purge the entire "Latest News" content section in index.htm when doing so, or don't touch the index.htm? Regards, Roland

Roland Schwarz wrote:
Thomas Witt wrote:
Roland Schwarz wrote:
I assume it's sufficient to perform the steps that are outlined in the release managers checklist as
# Verify the root/index.htm, root/boost/version.hpp, and root/Jamrules # release numbers are correct and agree.
But replace "Verify" with "Change". Correct?
Yep.
Do you think it would be possible to add the following
# On the main trunk: # Update the root/index.htm, root/boost/version.hpp and root/Jamrules # release numbers to n_(n+1)_0
to the duties of release manager for n_n_n ?
Makes sense to me. I'll go through the checklist tonight.
As you have been suggesting, I will do this on the main trunk for now.
But not the tagging I hope.
Shall I purge the entire "Latest News" content section in index.htm when doing so, or don't touch the index.htm?
Honestly, I've no idea. Thomas -- Thomas Witt witt@acm.org
participants (3)
-
David Abrahams
-
Roland Schwarz
-
Thomas Witt