Re: [Denemo-devel] Release 1.1

[Richard Shann]

On Mon, 2013-11-18 at 11:40 +0100, Éloi Rivard wrote:
> 
> 
> 
> 2013/11/17 Richard Shann <address@hidden>
>         On Sun, 2013-11-17 at 14:38 +0100, Éloi Rivard wrote:
>         > Did you run ./autogen and ./configure ?
>         
>         I was downloading and building from scratch (as a separate
>         user, not
>         associated with development). In other words, I was playing
>         the role of
>         a new user downloading and building the release (as best I
>         could).
> This is what Travis does, tag r1.1.0 seems ok here :
> https://travis-ci.org/denemo/denemo/builds/13463982 


Does it? - could it? - generate a tarball that we could test (to see if
it actually generated version 1.1.0).


> 
>         There is no autogen.sh in these release tarballs, that step is
>         already
>         done.
>         >  Because menu.c is a file that has been created after the
>         1.1.0 tag,
>         > so it is normal it does not exist when you build it.
>         
>         which means that the set of files in the tarball is
>         inconsistent. Which
>         will be down to some misunderstanding about how to use tags.
>         
>         
> Ok that is what I did not understood, you try to build from the
> tarball and not the repository. 

This is essential if we are to ensure that the file we post on
ftp.gnu.org can be used to install denemo by configure-make-make
install.


> That may mean that the tarball generation is inconstant, I will check
> that and add make it automatically checked in Travis.
> 
> Why do you think it is related to tags ? 

because that is what has changed since the last release.


> 
>         >
>         > Branches are supposed to use to bring fixes or features, and
>         tags are
>         > supposed to mark releases. Git internally handle them
>         differently. It
>         > is a bit easier to differentiate releases and feature code
>         when you
>         > have a lot of branches (like me :) ).
>         
>         
>         Well, as each release branch started with the name stable_ and
>         then a
>         release number, this is not a strong argument.
>         
>         More seriously, this tag idea perhaps does not fit with how we
>         make
>         releases. We decide that the master branch looks like it is a
>         good state
>         (we used to freeze check-ins for a week or so, though as it
>         was mostly
>         me doing the development, we haven't done that recently) and
>         then make a
>         branch. Then we create a candidate release tarball and
>         binaries for
>         testing and send the denemo.pot off to translationproject.org.
>         During
>         the next few weeks we test (and hope others have picked up the
>         binaries
>         and tried them). If all is well we apply the translations,
>         generate a
>         tarball and binaries and check them for sanity and, all again
>         being well
>         we sign and upload them to ftp.gnu.org and announce the
>         release.
>         So there are always some changes to push to the release
>         branch, and in
>         principle there could be fixes that just applied to a release,
>         though we
>         are not at that level of sophistication and always just tell
>         people to
>         get the latest release.
>         I don't know whether this fits the tag thing well, but there
>         needs to be
>         something in return for learning new git concepts and new
>         syntax (I am
>         hopeless at all that, but fortunately others have always
>         helped with
>         this side of things).
>         
>         Richard
>         
>         
> This is a quite common workflow :), and this is why one can change the
> commit for which a tag stands for.

I don't know much about this as I say, but "change the commit for which
a tag stands for" does not seem to describe what is needed. There may
have been further commits to master (since the code that is to be in the
release was fixed upon but before the translations are ready to commit),
so the tag can't simply be moved forward on the master branch.


> 
> 
> If you want I can put some documentation on the website for how to use
> git for the Denemo workflow.

A set of steps to take at each stage would be very useful I think - I
have been using the ones you emailed for updating the translations etc,
this has been working well.

I hope I have not missed any of your comments - there was a long section
of quoted mail before your signature but I don't think it contained
anything new. I have deleted it from this email to keep the thread
legible.

Richard