let me suggest to create the GRASS 6.4.0 release branch the next
days to get started with stability tests. The last release is long time
ago and more and more efforts go into GRASS 7 (which is good).
Time to get 6.4.0 out of the doors, say, to bring it to our users.
While I am not keen on *heavy* backporting, we will certainly
maintain the branch (as we still do at low level for 6.3.x).
Is there any blocker (!) which prevents us from creating the
6.4.0 release branch?
let me suggest to create the GRASS 6.4.0 release branch the next
days to get started with stability tests. The last release is long time
ago and more and more efforts go into GRASS 7 (which is good).
Time to get 6.4.0 out of the doors, say, to bring it to our users.
I agree - but do we need to create a release branch in advance of the release? Any development in the 6.4 branch at present is intended for the 6.4.0 release anyway; it's not as if we need to branch off the release to allow development to continue in the devel branch, as all new development is going on in trunk.
I think to avoid having three separate branches (6.4 dev, 6.4 release and 7.0 dev/trunk) it would be best to only create the release branch immediately before 6.4.0 is tagged.
> let me suggest to create the GRASS 6.4.0 release branch the next
> days
Paul:
I agree - but do we need to create a release branch in advance of the
release? Any development in the 6.4 branch at present is intended for
the 6.4.0 release anyway; it's not as if we need to branch off the
release to allow development to continue in the devel branch, as all
new development is going on in trunk.
I think to avoid having three separate branches (6.4 dev, 6.4 release
and 7.0 dev/trunk) it would be best to only create the release
branch immediately before 6.4.0 is tagged.
I think Paul is right, create 6.4.0 release branch moments before 6.4.0rc1,
otherwise there is more backporting to do, which is a pain.
or is the idea to release rc1 in the next days?
I had some things I wanted to get done before 6.4.0-final, I added/
commented on a couple in the trac system yesterday, and I'll add a few
more as I can remember them
Hamish
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
let me suggest to create the GRASS 6.4.0 release branch the next
days
Paul:
I agree - but do we need to create a release branch in advance of the
release? Any development in the 6.4 branch at present is intended for
the 6.4.0 release anyway; it's not as if we need to branch off the
release to allow development to continue in the devel branch, as all
new development is going on in trunk.
I think to avoid having three separate branches (6.4 dev, 6.4 release
and 7.0 dev/trunk) it would be best to only create the release
branch immediately before 6.4.0 is tagged.
I think Paul is right, create 6.4.0 release branch moments before 6.4.0rc1,
otherwise there is more backporting to do, which is a pain.
or is the idea to release rc1 in the next days?
I think that is the idea. It took 6 months to get from 6.3RC1 to 6.3 release,
so if we would like to see GRASS64 out by the end of the year the 6.3RC1
is overdue by now. It would be much simpler if we had only GRASS64 and GRASS7 -
currently there is 6.2, 6.3, 6.4 and 7 on the download site.
Helena
I had some things I wanted to get done before 6.4.0-final, I added/
commented on a couple in the trac system yesterday, and I'll add a few
more as I can remember them
Hamish
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
On Oct 21, 2008, at 9:20 PM, Helena Mitasova wrote:
On Oct 21, 2008, at 7:39 PM, Hamish wrote:
Markus wrote:
let me suggest to create the GRASS 6.4.0 release branch the next
days
Paul:
I agree - but do we need to create a release branch in advance of the
release? Any development in the 6.4 branch at present is intended for
the 6.4.0 release anyway; it's not as if we need to branch off the
release to allow development to continue in the devel branch, as all
new development is going on in trunk.
I think to avoid having three separate branches (6.4 dev, 6.4 release
and 7.0 dev/trunk) it would be best to only create the release
branch immediately before 6.4.0 is tagged.
I think Paul is right, create 6.4.0 release branch moments before 6.4.0rc1,
otherwise there is more backporting to do, which is a pain.
or is the idea to release rc1 in the next days?
I think that is the idea. It took 6 months to get from 6.3RC1 to 6.3 release,
so if we would like to see GRASS64 out by the end of the year the 6.3RC1
oops - I meant GASS64RC1
is overdue by now. It would be much simpler if we had only GRASS64 and GRASS7 -
currently there is 6.2, 6.3, 6.4 and 7 on the download site.
Helena
I had some things I wanted to get done before 6.4.0-final, I added/
commented on a couple in the trac system yesterday, and I'll add a few
more as I can remember them
Hamish
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
On Wed, Oct 22, 2008 at 3:20 AM, Helena Mitasova <hmitaso@unity.ncsu.edu> wrote:
On Oct 21, 2008, at 7:39 PM, Hamish wrote:
Markus wrote:
let me suggest to create the GRASS 6.4.0 release branch the next
days
I think Paul is right, create 6.4.0 release branch moments before
6.4.0rc1, otherwise there is more backporting to do, which is a pain.
or is the idea to release rc1 in the next days?
Yes, I forgot to mention that idea.
I think that is the idea. It took 6 months to get from 6.3RC1 to 6.3 release,
so if we would like to see GRASS64 out by the end of the year the 6.3RC1
is overdue by now. It would be much simpler if we had only GRASS64 and
GRASS7 - currently there is 6.2, 6.3, 6.4 and 7 on the download site.
I agree. For a user it's becoming messy to understand which version
to choose.
Hamish:
I had some things I wanted to get done before 6.4.0-final, I added/
commented on a couple in the trac system yesterday, and I'll add a few
more as I can remember them
Well, it's unrealistic to hope that we resolve all bugs/enhancements.
I suggest to get out 6.4.0rc1 asap for reality check (especially also for the
Windows port). If backporting becomes to heavy, we could even re-do the
relbranch in future.
I suggest to get out 6.4.0rc1 asap for reality check (especially also for the
Windows port). If backporting becomes to heavy, we could even re-do the
relbranch in future.
Unfortunately I'm very busy now; I'll discuss my thesis on November the 18th, and I'm still working on it.
That means that I'm forced to delay the GRASS job after 11/18. I know that this is an annoying problem, but that's all I can do
IMHO, I think that we could release the 6.4.0 branch and delay the Windows binaries on late November.
Hello all.
Could we have some bug sorting party this weekend? I (hopefully) will
have free time this weekend to recompile devbranch6 and take a look at
current bug list. It would be good to at least re-tag some of bugs
which must be fixed before 6.4.0 goes out and which ones can wait till
GRASS 7 goes mainstream. I have not tested devbranch6 for some time
but IIRC there where some regressions comparing to 6.2/6.3 (in NVIZ).
Just my 0.002,
Maris.
2008/10/22 Markus Neteler <neteler@osgeo.org>:
On Wed, Oct 22, 2008 at 3:20 AM, Helena Mitasova <hmitaso@unity.ncsu.edu> wrote:
On Oct 21, 2008, at 7:39 PM, Hamish wrote:
Markus wrote:
let me suggest to create the GRASS 6.4.0 release branch the next
days
I think Paul is right, create 6.4.0 release branch moments before
6.4.0rc1, otherwise there is more backporting to do, which is a pain.
or is the idea to release rc1 in the next days?
Yes, I forgot to mention that idea.
Well, it's unrealistic to hope that we resolve all bugs/enhancements.
I suggest to get out 6.4.0rc1 asap for reality check (especially also for the
Windows port). If backporting becomes to heavy, we could even re-do the
relbranch in future.
On Wed, Oct 22, 2008 at 9:36 AM, Marco Pasetti <marcopstt@gmail.com> wrote:
Hi all,
I suggest to get out 6.4.0rc1 asap for reality check (especially also for
the
Windows port). If backporting becomes to heavy, we could even re-do the
relbranch in future.
Unfortunately I'm very busy now; I'll discuss my thesis on November the
18th, and I'm still working on it.
That means that I'm forced to delay the GRASS job after 11/18. I know that
this is an annoying problem, but that's all I can do
(good luck with your thesis)
IMHO, I think that we could release the 6.4.0 branch and delay the Windows
binaries on late November.
Please note: we are talking about release candidates here, not the final
release.
> I agree - but do we need to create a release branch in advance of the
> release? Any development in the 6.4 branch at present is intended for
> the 6.4.0 release anyway; it's not as if we need to branch off the
> release to allow development to continue in the devel branch, as all
> new development is going on in trunk.
>
> I think to avoid having three separate branches (6.4 dev, 6.4 release
> and 7.0 dev/trunk) it would be best to only create the release
> branch immediately before 6.4.0 is tagged.
I think Paul is right, create 6.4.0 release branch moments before 6.4.0rc1,
otherwise there is more backporting to do, which is a pain.
or is the idea to release rc1 in the next days?
I had some things I wanted to get done before 6.4.0-final, I added/
commented on a couple in the trac system yesterday, and I'll add a few
more as I can remember them
I would suggest leaving 6.4.0 for a while yet. Otherwise, you'll be up
to 6.123.0 by the time that we start thinking about releasing 7.0.
I'd be more concerned about 6.3.1, as there have been a fair number of
straightforward bug-fixes since 6.3.0.
On Wed, Oct 22, 2008 at 5:27 PM, Glynn Clements
<glynn@gclements.plus.com> wrote:
I'd be more concerned about 6.3.1, as there have been a fair number of
straightforward bug-fixes since 6.3.0.
Well, I know easily 50 fixes which I have NOT backported to 6.3.svn, knowing,
that 6.4.0.RCX is forthcoming soon. Many are related to portability, too.
So I do think that we need a 6.4.0 the next months (at least I won't go through
all those fixes to check if they are present in 6.3.svn - even the code layout
isn't reindented).
Hello all,
as I understood from Glynn, it's too early to release 6.4.0 as GRASS 7
is still too far away. I also agree with Markus, that we need to
release something for packagers, as more and more users are suggested
to use SVN version and not some semi-stable version from packages.
GRASS 6.3.0 was technical preview release - it was never promised to
be stable. I see no point in releasing 6.3.1 with just some fixes.
My proposal - let's make another "technical preview" from devbranch6
called i.e. 6.3.90 (just a devbranch6 tag within week or so) - we get
something out for users who don't compile GRASS, still it's not final
6.4.0, that should be stable and bug free, as main release between 6.2
and 7.0 should be.
Just my 0.002,
Maris.
2008/10/23 Markus Neteler <neteler@osgeo.org>:
On Wed, Oct 22, 2008 at 5:27 PM, Glynn Clements
<glynn@gclements.plus.com> wrote:
I'd be more concerned about 6.3.1, as there have been a fair number of
straightforward bug-fixes since 6.3.0.
Well, I know easily 50 fixes which I have NOT backported to 6.3.svn, knowing,
that 6.4.0.RCX is forthcoming soon. Many are related to portability, too.
So I do think that we need a 6.4.0 the next months (at least I won't go through
all those fixes to check if they are present in 6.3.svn - even the code layout
isn't reindented).
On Thu, Oct 23, 2008 at 8:31 AM, Maris Nartiss <maris.gis@gmail.com> wrote:
Hello all,
as I understood from Glynn, it's too early to release 6.4.0 as GRASS 7
is still too far away.
This reasoning is unclear to me. While I want to avoid GRASS 6.132.x,
there is no real problem to have a 6.6 is unavoidable.
In 6.4.svn are thousands (!) of fixes which don't reach the user yet
in an organized way.
I also agree with Markus, that we need to
release something for packagers, as more and more users are suggested
to use SVN version and not some semi-stable version from packages.
GRASS 6.3.0 was technical preview release - it was never promised to
be stable. I see no point in releasing 6.3.1 with just some fixes.
I agree.
My proposal - let's make another "technical preview" from devbranch6
called i.e. 6.3.90 (just a devbranch6 tag within week or so) - we get
something out for users who don't compile GRASS, still it's not final
6.4.0, that should be stable and bug free, as main release between 6.2
and 7.0 should be.
You mean, with bulk-copying 6.4.svn into 6.3.svn? Or by downgrading
devel_grass6 branch to 6.3.90 or likewise in include/version.h? Or
by creating a 6.3.90 relbranch from devel_grass6?
Hello Markus,
well - let's wait for other developer input (especially - do 6.4 has
to be last stable 6.x release).
I forgot about that include/VERSION file. Doh.
My idea was really simple - just create develbranch_6 tag called
6.3.9x and make only one change in that tag - include/VERSION. Test,
release. No branching, backporting. When we will receive feedback
about current develbranch_6 state, we can decide if it's ready to
become 6.4 (stable), or there are some areas that need to be worked
on. 6.3.0 was really good idea and worked well, still IMHO we need
more 6.3-like releases between our stable versions.
Others - don't waste time by pointing places where I'm wrong. Please,
give ideas how to avoid those looong times between releases. Thanks!
Maris.
2008/10/23 Markus Neteler <neteler@osgeo.org>:
On Thu, Oct 23, 2008 at 8:31 AM, Maris Nartiss <maris.gis@gmail.com> wrote:
Hello all,
as I understood from Glynn, it's too early to release 6.4.0 as GRASS 7
is still too far away.
This reasoning is unclear to me. While I want to avoid GRASS 6.132.x,
there is no real problem to have a 6.6 is unavoidable.
In 6.4.svn are thousands (!) of fixes which don't reach the user yet
in an organized way.
I also agree with Markus, that we need to
release something for packagers, as more and more users are suggested
to use SVN version and not some semi-stable version from packages.
GRASS 6.3.0 was technical preview release - it was never promised to
be stable. I see no point in releasing 6.3.1 with just some fixes.
I agree.
My proposal - let's make another "technical preview" from devbranch6
called i.e. 6.3.90 (just a devbranch6 tag within week or so) - we get
something out for users who don't compile GRASS, still it's not final
6.4.0, that should be stable and bug free, as main release between 6.2
and 7.0 should be.
You mean, with bulk-copying 6.4.svn into 6.3.svn? Or by downgrading
devel_grass6 branch to 6.3.90 or likewise in include/version.h? Or
by creating a 6.3.90 relbranch from devel_grass6?
On Wed, Oct 22, 2008 at 5:27 PM, Glynn Clements
<glynn@gclements.plus.com> wrote:
I'd be more concerned about 6.3.1, as there have been a fair number of
straightforward bug-fixes since 6.3.0.
Well, I know easily 50 fixes which I have NOT backported to 6.3.svn, knowing,
that 6.4.0.RCX is forthcoming soon. Many are related to portability, too.
So I do think that we need a 6.4.0 the next months (at least I won't go through
all those fixes to check if they are present in 6.3.svn - even the code layout
isn't reindented).
I'm not sure if this is what Glynn meant, but I ask - why does 6.3.1 have
to be released from the 6.3.0 release branch? Why not just release 6.3.1 straight from develbranch_6? I really don't see the need to always have a release branch for releases. IMHO it slows things down and is a major impediment to "release early, release often" working.
I feel a release branch is only needed when a stable release is being made from a branch and major development work is going to continue in that branch and needs to be isolated from the release. This did not apply to 6.3.0 (because it wasn't a stable release) and will not apply to the next release, whatever we call it (because major development work is now happening in trunk).
If the release of 6.4.0 means a feature freeze for 6.x, then I think we should not do it yet and should release more 6.3.x versions direct from develbranch_6 until we feel ready to freeze 6.x and gamble the future on 7.x. If on the other hand 6.4.0 does not mean a feature freeze and we are still going to be able to add new modules (e.g. from Summer of Code in 2009?) and there will be 6.5.x and 6.6.x releases, then I don't see a problem with going ahead with 6.4.0 but I think if we are careful to manage features and bug fixes then there is no need for a release branch. Three branches would be really awkward for backporting and I feel we should avoid it if at all possible.
>> I'd be more concerned about 6.3.1, as there have been a fair number of
>> straightforward bug-fixes since 6.3.0.
>
> Well, I know easily 50 fixes which I have NOT backported to 6.3.svn, knowing,
> that 6.4.0.RCX is forthcoming soon. Many are related to portability, too.
> So I do think that we need a 6.4.0 the next months (at least I won't go through
> all those fixes to check if they are present in 6.3.svn - even the code layout
> isn't reindented).
I'm not sure if this is what Glynn meant, but I ask - why does 6.3.1 have
to be released from the 6.3.0 release branch? Why not just release 6.3.1
straight from develbranch_6? I really don't see the need to always have a
release branch for releases. IMHO it slows things down and is a major
impediment to "release early, release often" working.
Any release from develbranch_6 will contain incompatible changes, so
it should be called 6.4.0, not 6.3.1. Versions which share the same
major and minor numbers, differing only in the release number,
shouldn't have even minor incompatibilities.
Ideally, such versions should retain build-time compatibility as well
as run-time compatibility, so that third-party code will continue to
work in spite of any update.
I'd be more concerned about 6.3.1, as there have been a fair number of
straightforward bug-fixes since 6.3.0.
Well, I know easily 50 fixes which I have NOT backported to 6.3.svn, knowing,
that 6.4.0.RCX is forthcoming soon. Many are related to portability, too.
So I do think that we need a 6.4.0 the next months (at least I won't go through
all those fixes to check if they are present in 6.3.svn - even the code layout
isn't reindented).
I'm not sure if this is what Glynn meant, but I ask - why does 6.3.1 have
to be released from the 6.3.0 release branch? Why not just release 6.3.1
straight from develbranch_6? I really don't see the need to always have a
release branch for releases. IMHO it slows things down and is a major
impediment to "release early, release often" working.
Any release from develbranch_6 will contain incompatible changes, so
it should be called 6.4.0, not 6.3.1.
Ah OK now I see. Also as Helena said in private mail now that 6.4 is "out of the bag", so to speak, because 6.3.0 was released from its own branch and develbranch_6 was renamed to 6.4-SVN, users would see any 6.3.x versions released as being not up to date because they are aware that 6.4 is somehow available.
Not saying 6.3.1 from the 6.3 release branch is a bad idea, but I doubt anyone will have the motivation to merge the bugfixes and prepare a release. So I feel there is no real option but to go straight to 6.4.0. I'm still not sure if we need a release branch though.
On Fri, Oct 24, 2008 at 1:45 AM, Paul Kelly
<paul-grass@stjohnspoint.co.uk> wrote:
So I feel there is no real option but to go straight to 6.4.0. I'm still not
sure if we need a release branch though.
You mean we should just tag RC1 from develbranch_6?
We commonly used a release branch so far to avoid breakage.
Yes, it is a bit risky going ahead with no release branch. It would mean we would have to be very careful deciding what went into 6.4, and if an incompatible change was to be made at some time in the future, a release branch would have to be created *at that stage*, to preserve the functional state of 6.4 in order to create future 6.4.x bugfix releases if necessary.
My point is just that it would be a huge headache having three branches - backporting from 7.x to 6.x is already enough work - and if we felt that develbranch_6 is quite stable already we could probably manage the 6.4.0 release without creating a new branch. As far as I can see, commits to develbranch_6 consist mostly of bugfixes already at this stage, so this might not be too hard to do?
I still think at some point a 6.4 release branch will be needed (when we want to add new features) but I think we should put off creating it as long as possible to reduce work. That's all - it depends on other developers agreeing to restrict the changes we make to develbranch_6 for a while though.
I still think at some point a 6.4 release branch will be needed (when we
want to add new features) but I think we should put off creating it as
long as possible to reduce work. That's all - it depends on other
developers agreeing to restrict the changes we make to develbranch_6
for a while though.
If only to keep options open for a possible 6.5/6 release we'll eventually
need a releasebranch_6_4. For stability reasons this should be done, at
minimum, before the last (say) two RCs before the final release -- ie the
onset of the hard freeze.
Because this is likely to be the last new-features release before 7.0,
and that "may be some time", I don't mind a softer freeze a little later
than normal. What does a soft-freeze mean? I'd say keep going as we have
been with devbr6, and rely on developer discipline to not commit anything
too radical. As we already have an outlet for radicalness with gr7, I
don't think it will be too hard.
So my 2c plan of action would be to first finalize the module list (trac
task #344) in the next week by bringing over addons destined for main.
Once that is done we could tag a release_$DATE_grass_6_4_0RC1 directly
from devbr6 and declare devbr6 to be temporarily in stability mode.
Once r.out.gdal and other critical issues are dealt with, and the newly
merged modules have had a chance to settle in (inevitable portability
issues that pop up, etc) we could tag another RC, say 3 weeks after RC1.
We can decide at that point if RC2 will be the bugfix-only branch point
or again tagged directly from devbr6. No way of knowing, but it seems
reasonable to me to expect that RC2 could be the branch point.
After the release branch point, backports to that branch will be naturally
kept in check by the PITA that it is to sync things.
A question remains for me wrt after 6.4.0 is released if grass7<->devbr6
development will be kept in sync as it is now. (for possible 6.5/6)
I'll defer an opinion about that until the time of the last 6.4.0 RC.
