Discussion:
[Gramps-devel] snapshot build vs release build
Josip
2017-06-25 21:45:32 UTC
Permalink
Hi devs,
what is yours opinion on putting snapshot build on our github release
page in release section that is marked as "pre-release" or somewhere else.

For example v5.0.0-alpha2 is released 15 days ago for public testing and
since then we receive some bug report and fix them. Problem is that some
bugs that was already fixed prevent users to do further test and they
have to wait for v5.0.0-alpha3.
Making new git tag require additional preparation and for such small
change have no sense.

I am thinking of making build with "git describe" name, currently it
will be "v5.0.0-alpha2-33-g59c97081b". Such name will sort nicely,
downloaders will see how many updates this version is older then
original one, developers can do checkout on hash number. There is also
automatic number of commits since release in description of release
section on page so it is easy to compare them.

Build will be branded in same manner and will have same version as
mentioned "git describe".
--
Josip
Paul Franklin
2017-06-25 22:26:10 UTC
Permalink
Post by Josip
Hi devs,
what is yours opinion on putting snapshot build on our github release
page in release section that is marked as "pre-release" or somewhere else.
For example v5.0.0-alpha2 is released 15 days ago for public testing and
since then we receive some bug report and fix them. Problem is that some
bugs that was already fixed prevent users to do further test and they
have to wait for v5.0.0-alpha3.
Making new git tag require additional preparation and for such small
change have no sense.
I am thinking of making build with "git describe" name, currently it
will be "v5.0.0-alpha2-33-g59c97081b". Such name will sort nicely,
downloaders will see how many updates this version is older then
original one, developers can do checkout on hash number. There is also
automatic number of commits since release in description of release
section on page so it is easy to compare them.
Build will be branded in same manner and will have same version as
mentioned "git describe".
I am all in favor of anything which gets our most-current
code out there, as fast and as often as easily possible,
so people can test it, conveniently (for them).

I have a deep faith that the more people who test things
the better. That's why I argued we should do an alpha2
release, even if there were known bugs and known things
which still needed to be done. I still feel that way.

But I wouldn't mind if an alpha3 was done, either. My
changes to the NEWS file would be minimal and the
ChangeLog files were made automatically. You guys
(Nick, Josip, John, Ross) did all the real work. But if
you don't want to do it so soon again, that's fine too!
Paul Culley
2017-06-25 22:40:11 UTC
Permalink
I'm also in favor of releases at a more consistent rate.
I'll note that there are a couple of bug fixes pending as PRs (that I
consider to be fairly important).

Paul C.
Post by Paul Franklin
Post by Josip
Hi devs,
what is yours opinion on putting snapshot build on our github release
page in release section that is marked as "pre-release" or somewhere
else.
Post by Josip
For example v5.0.0-alpha2 is released 15 days ago for public testing and
since then we receive some bug report and fix them. Problem is that some
bugs that was already fixed prevent users to do further test and they
have to wait for v5.0.0-alpha3.
Making new git tag require additional preparation and for such small
change have no sense.
I am thinking of making build with "git describe" name, currently it
will be "v5.0.0-alpha2-33-g59c97081b". Such name will sort nicely,
downloaders will see how many updates this version is older then
original one, developers can do checkout on hash number. There is also
automatic number of commits since release in description of release
section on page so it is easy to compare them.
Build will be branded in same manner and will have same version as
mentioned "git describe".
I am all in favor of anything which gets our most-current
code out there, as fast and as often as easily possible,
so people can test it, conveniently (for them).
I have a deep faith that the more people who test things
the better. That's why I argued we should do an alpha2
release, even if there were known bugs and known things
which still needed to be done. I still feel that way.
But I wouldn't mind if an alpha3 was done, either. My
changes to the NEWS file would be minimal and the
ChangeLog files were made automatically. You guys
(Nick, Josip, John, Ross) did all the real work. But if
you don't want to do it so soon again, that's fine too!
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Josip
2017-06-25 23:34:33 UTC
Permalink
Post by Paul Franklin
But I wouldn't mind if an alpha3 was done, either.
It will be probably done but alpha3 has certain goals which need to be
reached (roadmap) and scheduled release time may be shifted because of
that (what last release was released at scheduled time?).

I am talking of something between that.
Something which will allow "ordinary" user to keep pace with development
and more actively participate in the testing.
Something which will not require git source modification.
Something which will not have fixed release schedule but instead be made
when needed or asked for from user.
Something which will probably be only Windows or Mac bundles.
John Ralls
2017-06-26 04:40:29 UTC
Permalink
Post by Paul Franklin
But I wouldn't mind if an alpha3 was done, either.
It will be probably done but alpha3 has certain goals which need to be reached (roadmap) and scheduled release time may be shifted because of that (what last release was released at scheduled time?).
I am talking of something between that.
Something which will allow "ordinary" user to keep pace with development and more actively participate in the testing.
Something which will not require git source modification.
Something which will not have fixed release schedule but instead be made when needed or asked for from user.
Something which will probably be only Windows or Mac bundles.
We don’t necessarily have to roadmap alphas. We *could* just pump them out every two weeks (except note that I’ll be away for most of August so one or two of them wouldn’t have a Mac bundle) and save the roadmap for when we think that it’s good enough to call it “beta”.

But another thought: The bundles have the source code in them, so sufficiently sophisticated users can just replace it in their already installed app bundles. That's probably a bit much for “ordinary” users but I wonder how many of those are testing.

Regards,
John Ralls

Loading...