View mode: basic / threaded / horizontal-split · Log in · Help
January 04, 2013
Re: github release procedure
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
January 04, 2013
Re: github release procedure
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
January 04, 2013
Re: github release procedure
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
January 04, 2013
Re: github release procedure
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 ».
January 04, 2013
Re: github release procedure
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
January 04, 2013
Re: github release procedure
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
January 04, 2013
Re: github release procedure
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.
January 04, 2013
Re: github release procedure
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
January 04, 2013
Re: github release procedure
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
January 04, 2013
Re: github release procedure
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).
2 3 4 5 6 7 8
Top | Discussion index | About this forum | D home