Andrew Edwards:

> When submitting bug reports associated with this review, ensure they are earmarked [REG2.065-b1] or [BUG2.065-b1] for easy identification, retrieval and merger.

So far I am not finding many bugs in this. But when is the work on 2.066 going to start? There are many patches. And what's the focus (if it has one) of D 2.066? I suggest to warn/deprecate all that should be deprecated (built-in sort, old operator overloading, etc), and introduce some of the little breaking changes that we think are good (like implicit joining of adjacent string literals, etc).

Bye,
bearophile

On 1/20/2014 4:30 PM, bearophile wrote:
> So far I am not finding many bugs in this. But when is the work on 2.066 going
> to start? There are many patches. And what's the focus (if it has one) of D
> 2.066? I suggest to warn/deprecate all that should be deprecated (built-in sort,
> old operator overloading, etc), and introduce some of the little breaking
> changes that we think are good (like implicit joining of adjacent string
> literals, etc).

Let's get 2.065 released first.

On Tuesday, 21 January 2014 at 00:30:30 UTC, bearophile wrote:
> Andrew Edwards:
>
>> When submitting bug reports associated with this review, ensure they are earmarked [REG2.065-b1] or [BUG2.065-b1] for easy identification, retrieval and merger.
>
> So far I am not finding many bugs in this. But when is the work on 2.066 going to start? There are many patches. And what's the focus (if it has one) of D 2.066? I suggest to warn/deprecate all that should be deprecated (built-in sort, old operator overloading, etc), and introduce some of the little breaking

complex numbers
-property

On 21 Jan 2014 08:00, "eles" <eles@eles.com> wrote:
>
> On Tuesday, 21 January 2014 at 00:30:30 UTC, bearophile wrote:
>>
>> Andrew Edwards:
>>
>>> When submitting bug reports associated with this review, ensure they
are earmarked [REG2.065-b1] or [BUG2.065-b1] for easy identification, retrieval and merger.
>>
>>
>> So far I am not finding many bugs in this. But when is the work on 2.066
going to start? There are many patches. And what's the focus (if it has one) of D 2.066? I suggest to warn/deprecate all that should be deprecated (built-in sort, old operator overloading, etc), and introduce some of the little breaking
>
>
> complex numbers
> -property

First fish operators, then complex numbers /me thinks.

Also, wave farewell to any complex library C bindings. :)

Iain.

Andrew Edwards wrote:

> Beta testing for dmd 2.065 is under way. You can access the associated zip at [1] and view the current list of regressions at [2]. Make every effort to provide a thorough review so we can get the best product out the door.
> 
> Please refrain from discussing the review here in the dlang.org forums. Instead, post all concerns to the dmd-beta mailing list at [3]. If you haven't already done so, you will need to register to the mailing list at [4].
> 
> When submitting bug reports associated with this review, ensure they are earmarked [REG2.065-b1] or [BUG2.065-b1] for easy identification, retrieval and merger.
> 
> [1] ftp://ftp.digitalmars.com/dmd.2.065.beta.1.zip
> [2]
> 
http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED
> [3] http://forum.dlang.org/group/dmd-beta
> [4] http://lists.puremagic.com/mailman/listinfo/dmd-beta

Can we *please* have a well-established, useful, naming scheme for tags and packages? 2.064beta3, 2.064beta4, 2.064.2, 2.065-b1... Are you as frustrated as me?

For starters, you guys should first decide should we have micro part of the version at all? (major.minor.micro-qualifier) Please decide a schema and all cases should be covered by it, including betas or what I would rather call candidate-releases or release-candidates.

From a standpoint of a RPM author - what I refer to as the "qualifier" (that is how OSGI names it) is basically a build-number of the package. Sometimes we, package maintaners have to rebuild set of packages because some configuration parameter had to be changed, or some file was missing, etc. Upstream should never specify this value. What upstream people should specify are major, minor and micro values. So, whatever you name your beta/rc/cr etc, please stick to the naming convention, otherwise it is going to make our life difficult.

I propose you name/tag the latest DMD package like the following: 2.065.rc1 . When release comes up, it will be tagged 2.065.0 if there are 2.065 hotfix releases, they should be tagged 2.065.1, 2.065.2, etc.

This is not my invention - smarted people than me come up with this, for a good reason.

-- 
Dejan Lekic
dejan.lekic (a) gmail.com
http://dejan.lekic.org

On 1/21/14, 2:20 PM, Dejan Lekic wrote:
> Can we *please* have a well-established, useful, naming scheme for tags and
> packages? 2.064beta3, 2.064beta4, 2.064.2, 2.065-b1... Are you as frustrated as
> me?

I was just in the process of addressing this. Based on recent issues with using the packaging scripts, I've changed the naming convention as follows:

	#.###.b#    // beta
	#.###.rc#   // release candidate
	#.#.0       // release
        #.#.#       // hotfix (where last # != 0)

That should solve any issues you may have.

On Tuesday, 21 January 2014 at 20:48:27 UTC, Andrew Edwards wrote:
> On 1/21/14, 2:20 PM, Dejan Lekic wrote:
>> Can we *please* have a well-established, useful, naming scheme for tags and
>> packages? 2.064beta3, 2.064beta4, 2.064.2, 2.065-b1... Are you as frustrated as
>> me?
>
> I was just in the process of addressing this. Based on recent issues with using the packaging scripts, I've changed the naming convention as follows:
>
> 	#.###.b#    // beta
> 	#.###.rc#   // release candidate
> 	#.#.0       // release
>         #.#.#       // hotfix (where last # != 0)
>
> That should solve any issues you may have.

Thank !

On Tuesday, 21 January 2014 at 20:48:27 UTC, Andrew Edwards wrote:
> On 1/21/14, 2:20 PM, Dejan Lekic wrote:
>> Can we *please* have a well-established, useful, naming scheme for tags and
>> packages? 2.064beta3, 2.064beta4, 2.064.2, 2.065-b1... Are you as frustrated as
>> me?
>
> I was just in the process of addressing this. Based on recent issues with using the packaging scripts, I've changed the naming convention as follows:
>
> 	#.###.b#    // beta
> 	#.###.rc#   // release candidate
> 	#.#.0       // release
>         #.#.#       // hotfix (where last # != 0)
>
> That should solve any issues you may have.

That is absolutely briliant Andrew! Now we can use my SPEC file to build new DMD RPMs whenever there is a new release (tag) on GitHub!