On 2013-11-14 09:39, luka8088 wrote:

> Just a wild thought...
>
> Maybe we can have monthly release and still keep it stable. Imagine this
> kind of release schedule:
>
> Month #  11          12          1           2           3
>
>           2.064       2.065       2.066       2.067       2.068
>           2.065rc2    2.066rc2    2.067rc2    2.068rc2    2.069rc2
>           2.066rc1    2.067rc1    2.068rc1    2.069rc1    2.070rc1
>           2.067b2     2.068b2     2.069b2     2.070b2     2.071b2
>           2.068b1     2.069b1     2.070b1     2.071b1     2.072b1
>           2.069alpha  2.070alpha  2.071alpha  2.072alpha  2.073alpha
>
> Where new features are only added to alpha release. And bug fixes are
> added to all releases.
>
> This way new bug fixes and new features would be released every month
> but there would be a 5 month delay between the time that feature A is
> added to the alpha release and the time feature A is propagated to the
> stable release. But during this period feature A would be propagated
> through releases and there would be plenty of opportunity to test it and
> clear it of bugs. I am not a fan of such delay but I don't see any other
> way new features could be added without higher risk of bugs.
>
> Also vote up for daily snapshots.

Are you saying we should have six releases going on at the same time?

-- 
/Jacob Carlborg

Am 14.11.2013 06:05, schrieb Tyro[17]:
> On 11/13/13, 11:30 PM, Andrej Mitrovic wrote:
>> On 11/14/13, Brad Anderson <eco@gnuk.net> wrote:
>>> 6 months between releases means a regression that was introduced in the latest version requires you to wait another 6 months for the fix which means you are running a version that is a year out of date.
>>
>> 6 months is ridiculously long. The changelog itself will have to span pages. And because a lot of people do not use DMD-head we'll end up with a ton of regressions that are only caught after a release is made. And people who want an important fix will have to wait 6 months for a release. New library features or modules will only be properly tested after a release, so that means potentially waiting 6 months with very little feedback.
>>
>> IMO 6 months is unacceptably long. We're not steering an oil rig here, D is supposed to be a speedboat.
>>
> 
> It's been approximately six months since the release of 2.063 (alright five+: May 28 to Nov 5). I don't think too many of us lost sleep over that. There is nothing ridiculously long about six months.
> 

Just a little personal impression - it seems like during 2.064's development, more people than ever have switched to DMD HEAD instead of the last release version. This made it much more burdensome to support public libraries, because compiler induced breakage was much more frequent.

So considering the *current* way releases are done, I'd be very much in favor of a shorter release schedule, maybe 3 months (remember that there were times where the cycle was about 1 month), so that there is less pressure to go GIT HEAD.

However, regular point releases and betas would arguably achieve this, too, so if the proposed plan is actually really followed like that, I'm all for it.

On 2013-11-14 10:02, growler wrote:

> Would this still be a problem though if GDC and LDC align to the beta
> release schedule?

I would guess so. The problem is that the longer we wait the more code will have change, which means harder to merge with GC and LDC. Unless they continuously merge.

-- 
/Jacob Carlborg

On Thursday, 14 November 2013 at 05:05:39 UTC, Tyro[17] wrote:
> It's been approximately six months since the release of 2.063 (alright five+: May 28 to Nov 5). I don't think too many of us lost sleep over that. There is nothing ridiculously long about six months.
>
I'm not using HEAD either and its annoying having to wait for updates with useful fixes and changes.  Also, longer cycles means more breakage for people who run the "stable" release.

> What I am proposing is that you get a package every month. That should be enough time to ferry out any regression that may crop up. Use the betas on a monthly basis and you get to ride the bullet train.

The problem here is the beta becomes the de facto stable because people want to be able to use the new things that the documentation says they can and the breakage is amortised over months, rather than coming in a huge spike every half year.  This really needs to be avoided.  If you look at the movement of active projects in the past few years, most seem to be settling on shorter release cycles for similar reasons.

-Wyatt

On Thursday, 14 November 2013 at 00:37:38 UTC, Tyro[17] wrote:
> ...
>
> Your thoughts and concerns please.

Key problem here is that you call by beta something that is really not a beta. It is short term support release similar to ones we currently have with a shorter release schedule. And if it is _really_ supposed to be beta (== with some potentially unfixed regressions remaining) it is not really usable even in bleeding edge code.

I have been proposing for ages to take existing http://wiki.dlang.org/Release_Process and define long-term support releases on top of it (== "normal" releases in your proposal). That way one can do releases once in 2 months to keep stuff going and mark ones as LTS once in a 6 months (with intention to backport non-breaking fixes into last 2 LTS) for users that want more stability.

It fulfills same goals but does not result in broken releases / confusing naming.

On 11/14/13, Sönke Ludwig <sludwig@outerproduct.org> wrote:
> Just a little personal impression - it seems like during 2.064's development, more people than ever have switched to DMD HEAD instead of the last release version. This made it much more burdensome to support public libraries, because compiler induced breakage was much more frequent.

And a 6 month release schedule means you have to keep around and implement workarounds in your libraries for old bugs. You can't just target git-head for your users, you have to target the latest stable version.

The release cycle right now is so slow that most of the time I'm just using git-head, but I still end up having to implement workarounds for the last stable version when I publish code. If the release cycles were more frequent then I wouldn't have to use bleeding-edge.

On Thursday, 14 November 2013 at 00:37:38 UTC, Tyro[17] wrote:
[...]
> Your thoughts and concerns please.

Please do not mix together bugs fix releases with enhancement/new addition releases, those represent two different types of release that serve two entirely different purposes.

Bug fixes should be as frequent as possible. To understand why, just try and find a good reason to artificially hold back a bug fix.

As for feature enhancements and new additions to the language, delays tend to be a good thing, allowing time for fine tuning reflection and beta testing - but please take note that the current process lacks a public beta release cycle, and we can see the results each time there's been a new release, with weird version number mix ups, and embarrassing bugs that would have been detected had there been a real public beta release posted on the main download page.

--rt

On Thursday, 14 November 2013 at 20:27:23 UTC, Rob T wrote:
> Bug fixes should be as frequent as possible. To understand why, just try and find a good reason to artificially hold back a bug fix.

Code breakage. DMD has good amount of accepts-invalid bugs.

On Thursday, 14 November 2013 at 00:37:38 UTC, Tyro[17] wrote:
> Greetings,
>
> I have accepted the responsibility of preparing the builds for DMD and would like to engage in conversation about the way ahead.
>
> The first concern I have is about the build cycle. Presently, it is nonexistent. There is no rhyme or reason regarding when releases are produced. The v2.065 agenda (first attempt of its kind) suggests that the next release will occur sometime in March 2014. I'm of the opinion, however, that the cycle should be six months long. This particular schedule is not of my own crafting but I believe it to be sound and worthy of emulation:
>
> ...
>
> Your thoughts and concerns please.

I think this is perfect. It's essentially what I would do. Ever since Google defined their six week release schedule for Chrome, people think quick release cycles are the next great thing. It was such an effective marketing strategy that Firefox had to jump the bandwagon. The truth is though, it doesn't cater well to large corporations. That's why Firefox also has ESR (Extended Support Release) for corporations which are older versions maintained for longer, only being updated for new bug and security fixes.

I think the majority of people active on these forums are hardcore D enthusiasts so they're eager to have the latest and greatest. However, we're not hearing the voice of those on the outside. I'm willing to bet if we were to post this as news on Reddit, we'd be getting praise from those who aren't actively involved in the development of D.


I do have a few ideas:

I'm one who favors having different version numbers for beta and stable releases. Given the version number scheme that DMD follows, a simple numbering scheme to follow is odd- and even-numbered versions: odd-numbered versions, starting with 2.065, would be beta, and even-numbered versions, like 2.066, would be stable.

I would define two periods during the release cycle: Early on, when it's okay to introduce new features and changes which may break code, and later on when we should be concentrating on testing, fixing bugs, and generally working towards a stable release.

Finally, I think after every stable release, we should define an agenda, i.e. what are our goals for the next version? My current impression is that pull requests are incorporated into master whenever they're deemed ready. If we have a clear agenda, then we could collectively focus our efforts into a few areas for development.

On Thursday, 14 November 2013 at 20:30:40 UTC, Dicebot wrote:
> On Thursday, 14 November 2013 at 20:27:23 UTC, Rob T wrote:
>> Bug fixes should be as frequent as possible. To understand why, just try and find a good reason to artificially hold back a bug fix.
>
> Code breakage. DMD has good amount of accepts-invalid bugs.

Right now I have 15 tests failing in SDC test suite because of DMD messing up with closures.

This is certainly not an option to wait 6 month that way. Accept invalid is certainly not something you can stick in patches release, but invalid codegen is.

I fairly bummed by code breakage being raised as a excuse to not do anything. As a matter of fact, I have to work with my own homebrew version of DMD half of the time. One release out of 2 has introduced unacceptable regression.

Now I'm ready to hear that people don't want to spend time publishing a minor version of DMD because they don't have time or whatever. But this breaking code bullshit must stop.

Every single release of DMD break my code, 1 release out of 2 break it by introducing regression, not because of accept-invalid (which I'm happy to fix).

We need these minor release. Anyone that have a reasonably sized D codebase knows it. In fact I'm pretty sure that anyone having a reasonably sized D codebase is using some homebrew version of DMD most of the time, as waiting 6 month is usually not an option.