D versionning

[Adam Wilson]

On Thu, 12 Jul 2012 14:57:31 -0700, deadalnix <deadalnix at gmail.com> wrote:

> On 12/07/2012 21:25, Jonathan M Davis wrote:
>> There would definitely be value in the long run in having a similar  
>> versioning
>> scheme, but I think that we're still ironing enough out that there's  
>> not much
>> point yet. We don't want people to continue to code against verison  
>> 2.X.Y
>> instead of moving their code to 2.X+1.Y. We want people to update their  
>> code
>> to the newest version. We provide appropriate deprecation paths to ease
>> transition, but we don't want to be supporting older versions of stuff.  
>> If you
>> really want to stick with what dmd 2.059 provides because 2.060  
>> deprecates
>> something that you want, then just stick with 2.059. You don't need a  
>> new
>> versioning scheme to do that.
>>
>
> You may want to benefit from bug fixes even if you don't want to migrate  
> to the new functionality yet. Sticking with 2.059 is somehow problematic.

This. 1000% this. New functionality is fundamentally different and placing  
bug fixes in the same development cycle is ridiculous to the point that no  
successful software endeavor I know of to date has ever considered it a  
viable strategy much less promoted it's use. I don't necessarily WANT to  
upgrade my DMD all the time to the latest, but I have on choice to get the  
latest set of bugfixes. It would also make the task of adding new features  
much simpler, you can pull the fix merges into both trees, and maintain a  
stable branch, a development branch. You'll note that the versioning  
system tends to work well with this model.

For example:
2.0.60 is the current HEAD. Bug fixes Only.
2.1.60 is the new feature branch. It is a GitHub fork of the current  
DMD-HEAD owned by the same org as current DMD-HEAD. This way Walter can  
work against both simultaneously.

We could have rolled the Object const change in 2.1.60, found out we  
didn't like them but instead of being FORCED to revert it to keep 2.060  
stable, we could have continued developing and improving the model or  
working on the problem from a completely different angle, WITHOUT  
affecting the release of 2.0.60.

We could keep all the COFF work in the DMD 2.1 branch without affecting  
DMD 2.0 branch and having nearly as many breakages as we currently do in  
HEAD. Most recently, the ElfObj breakage. Roll that work into 2.1.60 and  
if it breaks well, you KNEW you were on the development branch, what's  
your problem?

The stable/development branch model exists for a reason, it works, well.  
We don't have to keep rediscovering the models that worked successfully  
for other teams the hard way. If we proactively seek best practices, we  
can proactively avoid a huge amount of pain.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/