January 08
On Wednesday, 3 January 2018 at 04:50:51 UTC, Martin Nowak wrote:
> We would still keep the bi-monthly releases, but make them point releases.
> So new additions could still be released regularly, but breaking changes and deprecations would have to wait until the next major release.

You probably mean minor releases. Point ones can only contain bug fixes and no features.


January 14
On Monday, 8 January 2018 at 06:21:05 UTC, Dicebot wrote:
> On Wednesday, 3 January 2018 at 04:50:51 UTC, Martin Nowak wrote:
>> We would still keep the bi-monthly releases, but make them point releases.
>> So new additions could still be released regularly, but breaking changes and deprecations would have to wait until the next major release.
>
> You probably mean minor releases. Point ones can only contain bug fixes and no features.

Yes, semver uses the less confusion terms MINOR (bi-monthly) and PATCH (bugfixes).
January 14
On 2018-01-14 20:04, Martin Nowak via Dlang-internal wrote:
> On Monday, 8 January 2018 at 06:21:05 UTC, Dicebot wrote:
>> On Wednesday, 3 January 2018 at 04:50:51 UTC, Martin Nowak wrote:
>>> We would still keep the bi-monthly releases, but make them point releases.
>>> So new additions could still be released regularly, but breaking changes and deprecations would have to wait until the next major release.
>> 
>> You probably mean minor releases. Point ones can only contain bug fixes and no features.
> 
> Yes, semver uses the less confusion terms MINOR (bi-monthly) and PATCH
> (bugfixes).

How would that work in terms of development?
Would we need another branch for deprecations and breaking changes?
January 27
On Sunday, 14 January 2018 at 19:11:33 UTC, Sebastian Wilzbach wrote:
> How would that work in terms of development?
> Would we need another branch for deprecations and breaking changes?

No, master would only get merged into stable every 6 month or so.
It means that more development focus would shift towards stable though.
March 08
On Wednesday, 1 November 2017 at 10:48:15 UTC, Martin Nowak wrote:
> v8.0.0 - Jan 1 2018
> v8.0.x - unscheduled patch releases
> v8.1.0 - Mar 1 2018
> v8.1.x - unscheduled patch releases
> v8.2.0 - May 1 2018
> v8.2.x - unscheduled patch releases
> v9.0.0 - Jul 1 2018
> v9.0.x - unscheduled patch releases
> v9.1.0 - Sep 1 2018
> v9.1.x - unscheduled patch releases
> v9.2.0 - Nov 1 2018
> v9.2.x - unscheduled patch releases
> v10.0.0 - Jan 1 2019
> v10.0.x - unscheduled patch releases

Would make sense to release previews of the upcoming major release, maybe every other month to stick with todays pace.

April 06
On Thursday, 8 March 2018 at 18:25:44 UTC, Martin Nowak wrote:
> On Wednesday, 1 November 2017 at 10:48:15 UTC, Martin Nowak wrote:
>> v8.0.0 - Jan 1 2018
>> v8.0.x - unscheduled patch releases
>> v8.1.0 - Mar 1 2018
>> v8.1.x - unscheduled patch releases
>> v8.2.0 - May 1 2018
>> v8.2.x - unscheduled patch releases
>> v9.0.0 - Jul 1 2018
>> v9.0.x - unscheduled patch releases
>> v9.1.0 - Sep 1 2018
>> v9.1.x - unscheduled patch releases
>> v9.2.0 - Nov 1 2018
>> v9.2.x - unscheduled patch releases
>> v10.0.0 - Jan 1 2019
>> v10.0.x - unscheduled patch releases
>
> Would make sense to release previews of the upcoming major release, maybe every other month to stick with todays pace.

These versions make no sense at all as they have no meaning. Why making the change in the major version after 6 months? The API changes during that time may be minimal...

After seeing this I would propose you start doing similar what Java guys decided to do starting with the Java 18.3 (also called Java 10) - to use <year>.<month>.<release> where release is that month's release that increments from 0 up...
April 06
On 4/6/18 02:49, Dejan Lekic wrote:
> On Thursday, 8 March 2018 at 18:25:44 UTC, Martin Nowak wrote:
>> On Wednesday, 1 November 2017 at 10:48:15 UTC, Martin Nowak wrote:
>>> v8.0.0 - Jan 1 2018
>>> v8.0.x - unscheduled patch releases
>>> v8.1.0 - Mar 1 2018
>>> v8.1.x - unscheduled patch releases
>>> v8.2.0 - May 1 2018
>>> v8.2.x - unscheduled patch releases
>>> v9.0.0 - Jul 1 2018
>>> v9.0.x - unscheduled patch releases
>>> v9.1.0 - Sep 1 2018
>>> v9.1.x - unscheduled patch releases
>>> v9.2.0 - Nov 1 2018
>>> v9.2.x - unscheduled patch releases
>>> v10.0.0 - Jan 1 2019
>>> v10.0.x - unscheduled patch releases
>>
>> Would make sense to release previews of the upcoming major release,
>> maybe every other month to stick with todays pace.
>
> These versions make no sense at all as they have no meaning. Why making
> the change in the major version after 6 months? The API changes during
> that time may be minimal...
>
> After seeing this I would propose you start doing similar what Java guys
> decided to do starting with the Java 18.3 (also called Java 10) - to use
> <year>.<month>.<release> where release is that month's release that
> increments from 0 up...

I completely agree with this. I use some variation of year.month.x(.y) for all my projects. The point in time is non-arbitrary information and encoding it will make identifying builds that are compatible with given modules simpler: 18.x, 18.6, etc.

-- 
Adam Wilson
IRC: LightBender
import quiet.dlang.dev;
Next ›   Last »
1 2 3