The tag is there but it references the same commit as 2.061. This is
because the tag was made on the staging branch, which is correct. But
the staging branch hasn't been updated since the last release. (Which
is also correct, but we have to do one intermediate release with
special transition instructions. Otherwise we have two releases with
exactly the same content)
To determine what to do now, we have to know when this release is
supposed to be shipped. If we can delay it for ~1 Month we can make the
transition to the new release process now and the next release will
follow the new instructions 100%. If we want to release ASAP the next
release will be the intermediate release.
BTW: It's very important that the released beta zips are actually based
on the created tags! The current release is based on some recent
commit, although the tag is set to a commit from a month ago.

The tag is there but it references the same commit as 2.061. This is
because the tag was made on the staging branch, which is correct. But
the staging branch hasn't been updated since the last release. (Which
is also correct, but we have to do one intermediate release with
special transition instructions. Otherwise we have two releases with
exactly the same content)
To determine what to do now, we have to know when this release is
supposed to be shipped. If we can delay it for ~1 Month we can make the
transition to the new release process now and the next release will
follow the new instructions 100%. If we want to release ASAP the next
release will be the intermediate release.
BTW: It's very important that the released beta zips are actually based
on the created tags! The current release is based on some recent
commit, although the tag is set to a commit from a month ago.

I followed the instructions in the wiki. If they don't work, they need to be
revised.

I followed the instructions in the wiki. If they don't work, they
need to be revised.

You followed the instructions but nobody else did. For example bug
fixes weren't pushed to staging as described in 5.2.4 and therefore we
don't have any bug fix commits in staging now. The instructions on the
page can't work correctly if they are only partially followed.
I have to admit that the wiki page is missing instructions for the
transition to the new process. But as long as we don't have a clear
"Yes we want to use that process" statement from the core developers
there's no use in writing them. Right now it seems you're the only one
trying to follow that wiki page.

I have to admit that the wiki page is missing instructions for the
transition to the new process. But as long as we don't have a clear
"Yes we want to use that process" statement from the core developers
there's no use in writing them. Right now it seems you're the only one
trying to follow that wiki page.

Yes we want to use that process. I thought we made that clear through
talk and facts several times.
Thanks,
Andrei

I have to admit that the wiki page is missing instructions for the
transition to the new process. But as long as we don't have a clear
"Yes we want to use that process" statement from the core developers
there's no use in writing them. Right now it seems you're the only
one trying to follow that wiki page.

=20
Yes we want to use that process. I thought we made that clear through=20
talk and facts several times.
=20
Thanks,
=20
Andrei

Then I propose this:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D For 2.062 release =3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
* For this release, merge master into staging now
("5.3 Preparing a new major release", first code block).
* Delete the wrong tag:
git tag -d v2.062-b1
git push upstream :refs/tags/v2.062-b1
* Create the tag with the correct commit:
git checkout staging
git pull upstream staging
git tag v2.062-b1 #b1=3D>first beta
git push upstream v2.062-b1
(Update the dmd-beta.zip to match the content of the new tag)
* Continue working on the current release on the staging branch, create
tags/betas and the release as described on the wiki page (5.3 second
code block, 5.3 third code block).
* Fixes for the current release should go directly to staging, normal
development continues on master. Just as described in 5.2.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From now on =3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
* This also means from now on all pull requests should go to the
correct branches as described in 5.2. Things like the recent JSON
changes would get a feature branch, bug fixes to staging, smaller
enhancements to master.
(Everyone with push access to the official repo can push pull
requests to the correct branches, even if they target the wrong
branch on github.)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D For 2.063 release =3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The we'll have to make one small exception for the next release: Let's
say we plan to release 2.063 in 8 weeks, 5 April. Then we should merge
master into staging in 4 weeks, 8 March.
=46rom then on we can follow the instructions on the wiki 1:1.

I don't know what is the state of -b1 now, but it doesn't compile
my code.
dmd: func.c:1206: virtual void
FuncDeclaration::semantic3(Scope*): Assertion `type == f' failed.
It seemed fixed in previous state of master, so either the tag is
wrong or we have a regression. What is the state of 2.062-b1 ?

It seemed fixed in previous state of master, so either the tag is
wrong or we have a regression. What is the state of 2.062-b1 ?

The tag is still pointing to the wrong commit, somehow updating it
didn't work.
Maybe we should just do this release as usual. After this release has
been made we could discuss a release schedule first so that we now
when 2.063 will be released. And then we can make a clear plan on how
to switch to the new process.

The tag is there but it references the same commit as 2.061.
This is
because the tag was made on the staging branch, which is
correct. But
the staging branch hasn't been updated since the last release.
(Which
is also correct, but we have to do one intermediate release with
special transition instructions. Otherwise we have two releases
with
exactly the same content)
To determine what to do now, we have to know when this release
is
supposed to be shipped. If we can delay it for ~1 Month we can
make the
transition to the new release process now and the next release
will
follow the new instructions 100%. If we want to release ASAP
the next
release will be the intermediate release.
BTW: It's very important that the released beta zips are
actually based
on the created tags! The current release is based on some recent
commit, although the tag is set to a commit from a month ago.

Well it has been raised that the staging branch is kind of
useless. It was useful in early version, but several changes in
the process diminished its interest. Should we simply remove it ?
Anyway, Walter, you should first update the stagging branch via :
#Make sure you've read "Local repository setup"
git remote update
git checkout master
git pull upstream master
git checkout staging
git pull upstream staging
git merge master
git push upstream staging
I think you forgot that step.
On a side note, can we rename regression bug into something else
? The way it is used in the wiki is clearly note what is meant
when using the term regression usually. Released bug maybe ? Bug
in production ?

The tag is there but it references the same commit as 2.061.
This is
because the tag was made on the staging branch, which is
correct. But
the staging branch hasn't been updated since the last release.
(Which
is also correct, but we have to do one intermediate release with
special transition instructions. Otherwise we have two releases
with
exactly the same content)
To determine what to do now, we have to know when this release
is
supposed to be shipped. If we can delay it for ~1 Month we can
make the
transition to the new release process now and the next release
will
follow the new instructions 100%. If we want to release ASAP
the next
release will be the intermediate release.
BTW: It's very important that the released beta zips are
actually based
on the created tags! The current release is based on some recent
commit, although the tag is set to a commit from a month ago.

Well it has been raised that the staging branch is kind of
useless. It was useful in early version, but several changes in
the process diminished its interest. Should we simply remove it ?

It's still useful. It's supposed to be used for stabilization before an
actual release. The release branch is only used after the first release
has been made.
I actually like this concept, but you could also prepare releases on the
release branch. There are some drawbacks though. (For example a pull
request targeting an release branch could be valid before the release,
as we still allow all kinds of bug fixes then, but invalid after the
release as the criteria for which fixes are allowed changed).
The problem here is that the wiki page is missing instructions for the
transition from the old process to the new process. 5.3 suggest merging
master into staging _after_ an actual release, but this won't work for
the transition release as we won't get any new commits into staging (as
it happened now).
What we really need to do is agree on a release process - starting
the transition to the new process only makes sense if all contributors
really agree to use the new process. So we need all core developers to
issue their concerns, probably adapt the release process and then make
plans/instructions for the transition phase. And the _do_ the
transition.

It's still useful. It's supposed to be used for stabilization
before an
actual release. The release branch is only used after the first
release
has been made.

Yes I understand the benefit (I proposed the stagging branch in
the first place and wrote the first version of the process using
it).
But many other parts of the process and don't think it is worth
the extra work of keeping stagging and master in sync anymore. It
is an hard things, and we just failed at it. Granted, you have to
expect some error at the beginning. Let's see how it turns.
As of regression bugs ? It is unclear what they are (as by
definition, the proposed process make no sense to fix
regressions).

As of regression bugs ? It is unclear what they are (as by
definition, the proposed process make no sense to fix
regressions).

Maybe the definition should be made clearer. The main idea is
to never
introduce new bugs in maintenance releases. In the end the
contributor / release manager makes the judgement call.

We are far away from having a release manager. And it doesn't
make things clearer on subject. You basically avoided giving any
answer to that question by saying someone else should decide.
To me a regression is a bug that exist in version N+1 but doesn't
in version N. I though this definition was widespread, but
apparently it isn't as the described process make no sense in
case of regression.

We are far away from having a release manager. And it doesn't
make things clearer on subject. You basically avoided giving any
answer to that question by saying someone else should decide.

It's difficult to find a clear definition for what bugs should be fixed
in minor releases.

To me a regression is a bug that exist in version N+1 but doesn't
in version N.

The definition in the wiki is supposed to say exactly that. If it's
still unclear feel free to fix the definition.

I though this definition was widespread, but
apparently it isn't as the described process make no sense in
case of regression.

Why doesn't it make sense? In other projects minor releases are usually
bug fix releases so they don't introduce new functionality. If you take
dmd a _huge_ part of development is bug fixes and with that many fixes
it's likely that some introduce new bugs. But that's exactly what you
want to avoid when releasing a minor release. You want a release with
some bugs fixed and no new bugs introduced.
That's why I chose to only allow regression fixes: Regressions are
the most annoying bugs and often the only reason why people want a
minor release at all. For example:
2.061 works
2.062 introduces a new bug #1.
so #1 exists in 2.062 but not in 2.061 which exactly matches your
definition. Now everyone affected by #1 can't upgrade to 2.062.
Therefore #1 should be fixed in 2.062.1, 2.062.2 or some other minor
release. I don't know why this wouldn't make sense.

To me a regression is a bug that exist in version N+1 but
doesn't in version N.

The definition in the wiki is supposed to say exactly that. If
it's
still unclear feel free to fix the definition.

I try to understand the whole thing. If a bug exists in N+1, but
not in N, why does the process say that it should be fixed in N
and N+1 ? It make no sense.

That's why I chose to only allow regression fixes: Regressions
are
the most annoying bugs and often the only reason why people
want a
minor release at all. For example:
2.061 works
2.062 introduces a new bug #1.
so #1 exists in 2.062 but not in 2.061 which exactly matches
your
definition. Now everyone affected by #1 can't upgrade to 2.062.
Therefore #1 should be fixed in 2.062.1, 2.062.2 or some other
minor
release. I don't know why this wouldn't make sense.

OK understood. This seem over restrictive to me, as stuff like
ICE in the backend or wrong codegen deserve also such fix.
Basically anything that don't change the language.

To me a regression is a bug that exist in version N+1 but
doesn't in version N.

The definition in the wiki is supposed to say exactly that. If
it's
still unclear feel free to fix the definition.

I try to understand the whole thing. If a bug exists in N+1, but
not in N, why does the process say that it should be fixed in N
and N+1 ? It make no sense.

Where did you get that impression? We should really fix that part of
the wiki page.
5.2.5 says "The regression fix must be pushed to the oldest, still
supported version branch _affected_ by the regression."
As an extreme example:
N: 2.062 worked
N+1: 2.063 regression introduced
N+2: 2.064 still not fixed
N+3: 2.065 still not fixed
Then it should be fixed in N+1, N+2, N+3, staging and master. But it
should only be fixed in releases which are still supported. As that
wiki page proposes to support only one release, only N+3, staging and
master would receive the fix.

That's why I chose to only allow regression fixes: Regressions
are
the most annoying bugs and often the only reason why people
want a
minor release at all. For example:
2.061 works
2.062 introduces a new bug #1.
so #1 exists in 2.062 but not in 2.061 which exactly matches
your
definition. Now everyone affected by #1 can't upgrade to 2.062.
Therefore #1 should be fixed in 2.062.1, 2.062.2 or some other
minor
release. I don't know why this wouldn't make sense.

OK understood. This seem over restrictive to me, as stuff like
ICE in the backend or wrong codegen deserve also such fix.
Basically anything that don't change the language.

And that's why I said it's a judgement call. A wrong codegen fix can
also introduce new bugs. How likely it is to introduce new bugs
depends on the actual fix. In the end someone has to weigh the risk of
introducing new bugs and the use of that bug fix. Maybe it's possible
to add some more rules which come up when using the release process
though.