github release procedure

Rob T rob at ucora.com
Fri Jan 4 11:30:28 PST 2013


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 at 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


More information about the Digitalmars-d mailing list