Re: [Denemo-devel] Release 1.1

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

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. 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 ?

>
> 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.

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

>
>
>
> 2013/11/16 Richard Shann <address@hidden>
> I downloaded this and tried to build and it failed at the make
> stage:
>
> address@hidden:~/denemo-1.1.0$ make && make install
> make all-recursive
> make[1]: Entering directory `/home/denemo-user/denemo-1.1.0'
> Making all in tools
> make[2]: Entering directory
> `/home/denemo-user/denemo-1.1.0/tools'
> gcc -DHAVE_CONFIG_H -I. -I.. -g -O2 -pthread
> -I/usr/include/guile/2.0 -I/usr/include/libxml2 -pthread
> -I/usr/include/librsvg-2.0 -I/usr/include/glib-2.0
> -I/usr/lib/x86_64-linux-gnu/glib-2.0/include
> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/cairo
> -I/usr/include/libpng12 -I/usr/include/pixman-1
> -I/usr/include/freetype2 -pthread -lgthread-2.0 -lrt
> -lglib-2.0 -lsndfile -I/usr/include/glib-2.0
> -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -pthread
> -I/usr/include/gtk-3.0 -I/usr/include/pango-1.0
> -I/usr/include/gio-unix-2.0/ -I/usr/include/atk-1.0
> -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0
> -I/usr/include/freetype2 -I/usr/include/glib-2.0
> -I/usr/lib/x86_64-linux-gnu/glib-2.0/include
> -I/usr/include/pixman-1 -I/usr/include/libpng12 -pthread
> -I/usr/include/gtksourceview-3.0 -I/usr/include/libxml2
> -I/usr/include/gtk-3.0 -I/usr/include/pango-1.0
> -I/usr/include/gio-unix-2.0/ -I/usr/include/atk-1.0
> -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0
> -I/usr/include/freetype2 -I/usr/include/glib-2.0
> -I/usr/lib/x86_64-linux-gnu/glib-2.0/include
> -I/usr/include/pixman-1 -I/usr/include/libpng12 -pthread
> -I/usr/include/gtk-3.0 -I/usr/include/glib-2.0
> -I/usr/lib/x86_64-linux-gnu/glib-2.0/include
> -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/
> -I/usr/include/atk-1.0 -I/usr/include/cairo
> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/freetype2
> -I/usr/include/pixman-1 -I/usr/include/libpng12
> -I/usr/include/evince/3.0 -DUSE_EVINCE -D_HAVE_FLUIDSYNTH_
> -D_HAVE_RUBBERBAND_ -D_HAVE_PORTAUDIO_ -pthread
> -I/usr/include/aubio -D_HAVE_PORTMIDI_ -D_HAVE_X11_ -MT
> generate_source.o -MD -MP -MF .deps/generate_source.Tpo -c -o
> generate_source.o generate_source.c
> generate_source.c: In function ‘parse_menu_commands’:
> generate_source.c:102:20: fatal error: menu.c: No such file or
> directory
> compilation terminated.
> make[2]: *** [generate_source.o] Error 1
> make[2]: Leaving directory
> `/home/denemo-user/denemo-1.1.0/tools'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/home/denemo-user/denemo-1.1.0'
> make: *** [all] Error 2
>
> Would it make life simpler if we returned to using branches
> for releases? Is there some disadvantage?
>
> Richard
>
>
>
> On Fri, 2013-11-15 at 22:20 -0600, Jeremiah Benham wrote:
> > I have created a tarball for 1.1.0 testing now. I had to
> edit
> > configure.ac. For some reason I could not push the changes
> though.
> > Maybe I just don't know how to do it correctly.
> >
> >
> > Jeremiah
> >
> >
> >
> > On Tue, Nov 5, 2013 at 6:08 AM, Richard Shann
> > <address@hidden> wrote:
> > Jeremiah - can you create the release 1.1 tarball
> now for
> > sanity
> > checking before uploading to ftp.gnu.org?
> > The feature list for release 1.1 now looks like
> this:
> >
> > Palettes of commands
> > Customize content and shape
> > User created palettes
> > Movement Navigation Buttons
> > Buttons for quick change
> > Indication of current Movement
> > Raw LilyPond Output
> > For inclusion in user’s LilyPond template
> > Single keypress to update the output
> > Menu path to each command is shown
> > Tablature
> > Support for all instruments
> >
> > Upgrade Support
> > Keep custom shortcuts, palettes, etc on
> upgrading
> > Denemo
> > Command Center
> > Can stay open while working on score.
> > Replaces old Command Manager
> > Commands ordered by their labels
> > Incremental search for commands by label
> > Incremental search for strings within
> tooltips
> > Execute any command
> > Add any command to a palette
> >
> > Richard
> >
> >
> >
> > On Wed, 2013-10-23 at 20:53 +0100, Richard Shann
> wrote:
> > > I have just merged master into the stable-1.1.0
> branch to
> > re-start the
> > > release with all the fixes. I built this version
> for windows
> > (in
> > > denemo.org/~rshann/uploads) and tested it. I have
> sent the
> > denemo.pot
> > > off to the translation project and so now we need
> to give
> > the
> > > translators time to work on the (only slightly)
> updated pot
> > file.
> > >
> > > Richard
> > >
> > >
> > >
> > > _______________________________________________
> > > Denemo-devel mailing list
> > > address@hidden
> > >
> https://lists.gnu.org/mailman/listinfo/denemo-devel
> >
> >
> >
> > _______________________________________________
> > Denemo-devel mailing list
> > address@hidden
> > https://lists.gnu.org/mailman/listinfo/denemo-devel
> >
> >
> >
>
>
>
> _______________________________________________
> Denemo-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/denemo-devel
>
>
>
>
> --
> Éloi Rivard - address@hidden
>
> « On perd plus à être indécis qu'à se tromper. »
>

--
Éloi Rivard - address@hidden

« On perd plus à être indécis qu'à se tromper. »

From:	Éloi Rivard
Subject:	Re: [Denemo-devel] Release 1.1
Date:	Mon, 18 Nov 2013 11:40:07 +0100