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 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]
> [2]
> [3]
> [4]

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 

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

Dejan Lekic
dejan.lekic (a)

Reply via email to