Maxima version and git describe and git workflow

>>>>> "Robert" == Robert Dodier <robert.dodier at gmail.com> writes:

    Robert> On 2013-02-25, Raymond Toy <toy.raymond at gmail.com> wrote:
    >> In a recent message it was noted that the maxima version on the
    >> current master branch is something like 5.28.0_314.  This version
    >> comes from git describe which derives the version from the "closest"
    >> annotated tag.

    Robert> Yeah. I did 'git push' but not 'git push --tags' so the 5.29 tags I
    Robert> made weren't pushed. I've just now pushed tags so everybody should see
    Robert> branch-5_29-base, 5.29.0, and 5.29.1.

Thanks.  I see these tags now.

    >> Since we've released 5.29.x, it would make more sense if the version
    >> were something like 5.29_nnn.

    Robert> As it stands, and I don't see a reason to change this, releases are on
    Robert> branches, so a tagged release is not the ancestor of the most
    Robert> up-to-date commit on master. While I agree the version on master should
    Robert> somehow mention 5.29, it shouldn't be 5.29_<something>. Currently Git
    Robert> reports branch_5_29_base_<something> which is an accurate representation
    Robert> of the situation.

I'm happy with branch-5_29_base_<blah>, although that confuses me a
bit.  It makes me think I'm working on branch-5.29, but I'm actually
on master.

I wonder if it would work if, when branch-5_29-base were created, we
also added a 5.29post tag and describe would return 5.29post_<blah>?
That would seem better.

But since I'm not a release manager, I don't want to burden the
manager with even more work. 

    Robert> Yes, there are such tags. I forgot to push them. Sorry.

No problem.  I forget these things all the time.

    >> We might also have to merge
    >> that tagged version back to master to keep things consistent.

    Robert> I hope developers will carry out such merges since, to the best of my
    Robert> knowledge, nobody is making sure anybody else's branch commits get
    Robert> merged. Certainly I'm not.

I didn't follow the development of the 5.29 branch, but I'm assuming
there were some changes and presumably they should be merged back to
master.  Otherwise 5.29 has fixes that master doesn't?  If there's
nothing relevant, then we don't have to do anything.

I'm assuming developer's branches would be managed by the developer as
appropriate, and can be safely ignored by everyone except the
developer (and any helpers).  The release branches would seem to be
different in this aspect.

Ray