On Thu, 12 Jul 2012 14:57:31 -0700, deadalnix <deadal...@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/
