On Friday, 4 January 2013 at 18:35:18 UTC, deadalnix wrote:
> On Friday, 4 January 2013 at 17:26:02 UTC, Johannes Pfau wrote:
>> Am Fri, 04 Jan 2013 08:35:17 -0800
>> schrieb Jonathan M Davis <jmdavisProg@gmx.com>:
>>
>>> The thread was way too big, and I had too little time to get into
>>> that conversation, which is why I wasn't involved.
>>> 
>>> - Jonathan M Davis

OK, but it would have been a lot shorter had you and the other devs become involved ;)

> First, regression fix don't make any sense to me. You suggest to fix bug in master and fix regression in older branches. This should be the opposite IMO.
>
> A regression is something that used to work, but don't work anymore. So Correcting them in older version seems kind of contradictory, especially when other bugs aren't.
>
> I don't think separating those 2 type of bugs is really beneficial and I would keep only the process for regression fixes.

Terminology aside, we need to differentiate between bug fixes that do not introduce new bugs vs bug fixes that may introduce new bugs *or* break existing code for the current release version. We also *have* to prevent new features and structural changes (destabilizers) from leaking into a stable release.

> Secondly, in every git commands block you have all the commands to set-up the repository. I think this belong to its own paragraph or even its own page. Then I'd replace them with git remote update in git command block.
>
> Finally, it is weird that we have v2.062 -> v2.062.1 . I'd prefers v2.062.0 for the first one.

Absolutely! Otherwise someone is going to think v2.062 is greater than v2.062.1. Guaranteed. I already got semi-confused looking at the latest download page and I know what's going on far more than Joe Smith who walks in tomorrow checking out D for the first time.

> I like very much the ASCII art on top, which make thing really clear. Overall, it is better that the actual version on the wiki.

Looks good yes.

--rt

On Friday, January 04, 2013 20:30:28 Rob T wrote:
> Absolutely! Otherwise someone is going to think v2.062 is greater than v2.062.1. Guaranteed. I already got semi-confused looking at the latest download page and I know what's going on far more than Joe Smith who walks in tomorrow checking out D for the first time.

Really? Why on earth would you think that 2.062 was greater than 2.062.1? Also, I believe that it's very common with Linux packages (and probably the projects themselves) to do that sort of versioning where there's never a .0 and the last part only gets added when you actually get a .1.

- Jonathan M Davis

On Friday, 4 January 2013 at 17:11:54 UTC, Johannes Pfau wrote:
> The more I think about it, staging really seems to be useful to avoid
> some corner cases.

I haven't had time to study the newly proposed process in enough detail to properly comment, but it always seemed to me that you cannot get away without a staging branch. You can try very hard to do without, but it means something else will suffer for the lack of it, so it seems you are coming to the same conclusion which is good (unless I'm wrong).

If we look at how the current 2.061.0 release went down, there was clearly no staging at all, it went straight out just as it did in the past, and we're already seeing complaints about broken code and bug fixes that should have gone into the release that were left out. We're also finding bugs discovered right after the release was made, this is not good and should not happen.

The whole point of having a process has been defeated in terms of the goal of creating highly stable releases. What has been released is in effect a beta release or the same thing as a staging release, it is *not* a stable release! If it was a stable release, we would not see so many immediate problems.

I realize this was our fist pass through with an incomplete process, and almost no buy in from the devs who were to use it, so with that said we have clearly made some significant improvements, and I do not want to take away from that, however I hope we can all refocus on the goal of releasing only high quality software, not half baked betas.

Thanks!

--rt

On Friday, 4 January 2013 at 19:30:29 UTC, Rob T wrote:
> Terminology aside, we need to differentiate between bug fixes that do not introduce new bugs vs bug fixes that may introduce new bugs *or* break existing code for the current release version. We also *have* to prevent new features and structural changes (destabilizers) from leaking into a stable release.
>

Understood. The things is that it is more dependent of the code than of the bug itself.

Basically, it say that we should refuse risky bug fixes in released versions, and fix them into master. This probably should be specified at some point, but this is quite badly defined now, and I'm not sure this is really important to define this before actually using the process.

I'd go for a use you judgment here, or some very generic guideline like « if the bug fix require important refactoring, or change the behavior of an existing feature, then it should only be fixed in master ».

On Friday, 4 January 2013 at 19:59:19 UTC, Jonathan M Davis wrote:
> Really? Why on earth would you think that 2.062 was greater than 2.062.1?

I was asking for clarity so that no one can possibly get confused.

If you look at the download page, the .0 is missing on some of the packages, but shows up as a -0 on some of the others, and that is simply confusing and totally unnecessary. If it is necessary for some reason, then it needs to be explained.

> Also, I believe that it's very common with Linux packages (and probably the
> projects themselves) to do that sort of versioning where there's never a .0
> and the last part only gets added when you actually get a .1.

There's no law that states that we must follow old conventions.

--rt

On Friday, January 04, 2013 21:01:41 Rob T wrote:
> If we look at how the current 2.061.0 release went down, there was clearly no staging at all, it went straight out just as it did in the past, and we're already seeing complaints about broken code and bug fixes that should have gone into the release that were left out. We're also finding bugs discovered right after the release was made, this is not good and should not happen.

That's what the beta is for, which we did. Clearly, not enough people tried it out, or those regressions would have been caught. Creating a separate branch would not fix that.

- Jonathan M Davis

On Friday, 4 January 2013 at 19:59:19 UTC, Jonathan M Davis wrote:
> On Friday, January 04, 2013 20:30:28 Rob T wrote:
>> Absolutely! Otherwise someone is going to think v2.062 is greater
>> than v2.062.1. Guaranteed. I already got semi-confused looking at
>> the latest download page and I know what's going on far more than
>> Joe Smith who walks in tomorrow checking out D for the first time.
>
> Really? Why on earth would you think that 2.062 was greater than 2.062.1?
> Also, I believe that it's very common with Linux packages (and probably the
> projects themselves) to do that sort of versioning where there's never a .0
> and the last part only gets added when you actually get a .1.
>
> - Jonathan M Davis

Both debian and ubuntu uses version.of.software-packageversion

For instance :

$ apt-cache policy audacious
audacious:
  Installé : 3.2.4-1
  Candidat : 3.2.4-1
 Table de version :
     3.3.3-2 0
         10 http://ftp.fr.debian.org/debian/ experimental/main amd64 Packages
 *** 3.2.4-1 0
        990 http://ftp.fr.debian.org/debian/ testing/main amd64 Packages
        150 http://ftp.fr.debian.org/debian/ unstable/main amd64 Packages
        100 /var/lib/dpkg/status
     2.3-2 0
        800 http://ftp.fr.debian.org/debian/ stable/main amd64 Packages

3.2.4 is the version of audacious. 1 is the version of the package. Distro rarely interfers with the version of the software itself and simply resuse what software devs choose, adding their own system on top of it.

05-Jan-2013 00:01, Rob T пишет:
> On Friday, 4 January 2013 at 17:11:54 UTC, Johannes Pfau wrote:
>> The more I think about it, staging really seems to be useful to avoid
>> some corner cases.
>
> I haven't had time to study the newly proposed process in enough detail
> to properly comment, but it always seemed to me that you cannot get away
> without a staging branch. You can try very hard to do without, but it
> means something else will suffer for the lack of it, so it seems you are
> coming to the same conclusion which is good (unless I'm wrong).
>
> If we look at how the current 2.061.0 release went down, there was
> clearly no staging at all, it went straight out just as it did in the
> past, and we're already seeing complaints about broken code and bug
> fixes that should have gone into the release that were left out. We're
> also finding bugs discovered right after the release was made, this is
> not good and should not happen.

Staging branch was there, so did the betas.
What could have helped is announcing beta at D.announce instead of separate list. Plus at holidays there was not much of beta test coverage.


-- 
Dmitry Olshansky

On Friday, January 04, 2013 21:10:32 Rob T wrote:
> On Friday, 4 January 2013 at 19:59:19 UTC, Jonathan M Davis wrote:
> > Really? Why on earth would you think that 2.062 was greater than 2.062.1?
> 
> I was asking for clarity so that no one can possibly get confused.
> 
> If you look at the download page, the .0 is missing on some of the packages, but shows up as a -0 on some of the others, and that is simply confusing and totally unnecessary. If it is necessary for some reason, then it needs to be explained.
> 
> > Also, I believe that it's very common with Linux packages (and
> > probably the
> > projects themselves) to do that sort of versioning where
> > there's never a .0
> > and the last part only gets added when you actually get a .1.
> 
> There's no law that states that we must follow old conventions.

True, but you also shouldn't do something different just to do something different. You need a good reason.

I think that it's pretty ugly to have 2.062.0, and in my experience, that's a very abnormal thing to do. You have 2.062 followed by 2.062.1 if you ever have any point releases, but you don't start with .0. I don't recall ever seeing that before.

And the fact that with have -0 on the latest release on the download page is downright bizarre too. I don't think that I've ever seen -0 before either. I'd expect you to add the -1 if you ever need one but not start with -0. And actually, looking at my Linux box now, it looks like Arch starts with -1, not -0. I don't know what other distros do.

Regardless, I'm not at all in favor of having .0 on any release. Only add the minor versions to releases which are minor versions, not to the major ones.

- Jonathan M Davis

On Friday, 4 January 2013 at 20:48:34 UTC, Jonathan M Davis wrote:
> On Friday, January 04, 2013 21:10:32 Rob T wrote:
>> On Friday, 4 January 2013 at 19:59:19 UTC, Jonathan M Davis wrote:
>> > Really? Why on earth would you think that 2.062 was greater
>> > than 2.062.1?
>> 
>> I was asking for clarity so that no one can possibly get confused.
>> 
>> If you look at the download page, the .0 is missing on some of
>> the packages, but shows up as a -0 on some of the others, and
>> that is simply confusing and totally unnecessary. If it is
>> necessary for some reason, then it needs to be explained.
>> 
>> > Also, I believe that it's very common with Linux packages (and
>> > probably the
>> > projects themselves) to do that sort of versioning where
>> > there's never a .0
>> > and the last part only gets added when you actually get a .1.
>> 
>> There's no law that states that we must follow old conventions.
>
> True, but you also shouldn't do something different just to do something
> different. You need a good reason.
>
> I think that it's pretty ugly to have 2.062.0, and in my experience, that's a
> very abnormal thing to do. You have 2.062 followed by 2.062.1 if you ever have
> any point releases, but you don't start with .0. I don't recall ever seeing
> that before.
>
> And the fact that with have -0 on the latest release on the download page is
> downright bizarre too. I don't think that I've ever seen -0 before either. I'd
> expect you to add the -1 if you ever need one but not start with -0. And
> actually, looking at my Linux box now, it looks like Arch starts with -1, not
> -0. I don't know what other distros do.
>
> Regardless, I'm not at all in favor of having .0 on any release. Only add
> the minor versions to releases which are minor versions, not to the major
> ones.
>
> - Jonathan M Davis

I don't think anybody really care if this start with 0 or 1. What is weird is that you'll find 2 numbers versions and 3 numbers one, which is confusing (and I never saw that in any software).