If we add more commits to 1.3.8 branch, then branch 1.3.8 and
tag 1.3.8 will point to different places.
Clearly there could be errors after creating the release branch so there
would be several commits that appear on the release branch and on the
master branch. That's a bit annoying, but may happen. Nevertheless, once
the release happens and the release branch is tagged, there shouldn't be
any changes made to the release branch. In that sense branch an tag will
point to the same sha1 and one could actually delete the branch (the
commits will not dissappear, since there is a tag at the top of the
release branch).
(If we never make commits to 1.3.8 branch, then why create this branch?
We can make release on master branch then.)
Actually, we could start another development strategy.
*---*---*--- ... ---*------- devel branch
/ \
*----*-----------------------*----- master brach
1.3.7 1.3.8
Development happens on a devel branch. A release is then just a merge of
devel branch into the master branch and a tag on the master branch.
(Or above we call devel:=master and master:=release.)
As far as I understand Waldek created the 1.3.8 branch only to have an
extra commit that sets the version number. That is similar to the above
only that 1.3.7 is not a parent of 1.3.8.
I guess the simplest solution now would be to remove the branch names
1.3.7 and 1.3.8. They are the only "ambiguous" names. For all the other
tags there is no branch name.
Ralf
--
You received this message because you are subscribed to the Google Groups "FriCAS -
computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/fricas-devel/1b9583ea-3947-bab2-f414-83f7e7339089%40hemmecke.org.
