December 16, 2012
On Sunday, 16 December 2012 at 02:03:34 UTC, Jesse Phillips wrote:
> On Saturday, 15 December 2012 at 20:39:22 UTC, deadalnix wrote:
>> Can we drop the LTS name ? It reminds me of ubuntu, and I clearly hope that people promoting that idea don't plan to reproduce ubuntu's scheme :
>> - it is not suitable for a programming language (as stated 3 time now, so just read before why I won't repeat it).
>
> You don't need to repeat your self, you need to expand on your points. Joseph has already requested that you give specifics of your objection, you have explained why the situation is different but not what needs to be different.
>

This is completely backward, but I'll do it anyway. But first, let me explain why it is backward.

You are using distro's versionning system as a base of reflexion. But such system is made to achieve different goal than a programming language. I shouldn't be here explaining why this is wrong, you should be here explaining me why it can be applied anyway.

Otherwise, anyone can come with any point, whatever how stupid it is, and each time we have to prove that person wrong. When you come with something, you have to explain why it make sens, not the other way around.

Back to the point, and it will be the last time. A distro is a set of programs. The goal of the distro is to provide a set of programs, as up to date as possible, that integrate nicely with each other, and with as few bugs as possible. Some of these goals are in conflict, so we see different pattern emerge, with different tradeoff, as ubuntu and debians's processes.

From one version to another, distro don't need backward compatibility. Easy migration is important, but not compatibility. This is why debian can switch to multiarch in its next version (which break a hell lot of things). You don't need revision of the distro because software are updated on a per software basis when problems are detected (package in fact, but it don't really matter).

This is very different from a programming language where :
- no package update is possible. The concept of package don't even exist in our world.
- backward compatibility is a very important point, when it isn't for distros.

The only goal that is coming is trying to reach some level of stability. Everything else is completely different.

> Your points were specific to Debian's model, which is not Ubuntu's.
>
>> - ubuntu is notoriously unstable.
>
> I don't know anyone who uses the LTS releases. That isn't to say no one is, but Ubuntu is doing a lot of experimenting in their 6 month releases.

I used to work with ubuntu. I've done a ton of things with that distro. It IS unstable. In fact, it is based on debian unstable, so it isn't really a surprise.
December 16, 2012
On Sunday, 16 December 2012 at 03:59:33 UTC, Rob T wrote:
> On Thursday, 13 December 2012 at 07:18:16 UTC, foobar wrote:
>>
>> Per my answer to Rob:
>> D2 *is* the major version.
>> releases should be minor versions and largely backwards compatible - some evolution is allowed given some reasonable restrictions like a proper migration path over several releases.
>> Critical bug-fixes can go directly on stable releases but nothing else.
>>
>
> I just realized that we are mixing together the version numbers for two entirely different things.
>
> As you have correctly pointed out, one of the version numbers is for the D language specification, which is version 2.something, the other version is for the compiler releases, which has the major language specification version assigned to identify it as supporting version 2.something of the D language. The remaining numbers indicate incremental releases which may also roughly correspond to the minor evolutionary changes to the language specification, i.e., does DMD 2.061 also mean D specification 2.061?
>

Yes it does. If new features are introduced, then this is by definition a change in the specs.

> I think it makes good sense that the "2" is used to indicate that the compiler supports D major version 2 of the specification, but we should all be clear that is all that it represents. Therefore DMD 3.x will never appear unless there's a D language ver 3 specification for it to support.
>

A version 3 would means introducing change in the specification that may break a lot of code. This is type of stuff you shouldn't do often.

> A completely separate issue that should be dealt with, is that the language specification's version number is not indicated anywhere that I could see. We just assume it's version 2.something and we have no idea where the "something" part is currently at or what has changed since ver 2.0. This is no good because it means that we cannot indicate in the compiler release change log what minor version of the 2.x specification the compiler is actually supporting.
>

The compiler source code is probably what we have that look like the most as a spec right now.
December 16, 2012
On Sunday, 16 December 2012 at 07:35:27 UTC, deadalnix wrote:
>
> The only goal that is coming is trying to reach some level of stability. Everything else is completely different.
>

There are still some clear similarities between what Debian is doing and what I presume most people do in software development.

For the software I develop we have what is called a "live" branch, which is the code that is in active use by our customers. This branch corresponds to the stable branch we're trying to achieve, and it only gets critical bug fixes until the next major update which includes new features and/or major adjustments as well as non-critical bug fixes. We also have a testing branch, which includes the latest pre-release code for the next major update. This code is running on a VM and is tested by our customers (and the developers), under conditions similar to "live". There's also a common "dev" branch for the code which is in development but not yet ready for testing. This branch corresponds to the Dev (Master) Branch, The master branch gets updated from individual forks owned by each developer. Coordination among developers is essential to prevent duplications and major conflicts.

So in essence we're following a similar model to the Debian model of (Master Dev) which is "unstable " => Pre-release Testing => Stable.

It works great, and I see no way to remove any of the branches without seriously compromising the end result.

For example, we can't go directly from Dev to Stable, that would be like committing suicide. We can't use testing for dev updates, it's too destabilizing and we'd never get a properly tested stable release out unless all development updates were halted for a long period of time, but then the individual forks would pile up with major changes that would be very difficult to sort out when merged all back together.

We need 3 common branches, and I just don't see a way out of that.

BTW, I'm using Mercurial which has many similarities to Git. Unfortunately I don't know my way around Git very well at this time.

--rt
December 16, 2012
On Sunday, 16 December 2012 at 08:30:04 UTC, Rob T wrote:
> On Sunday, 16 December 2012 at 07:35:27 UTC, deadalnix wrote:
>>
>> The only goal that is coming is trying to reach some level of stability. Everything else is completely different.
>>
>
> There are still some clear similarities between what Debian is doing and what I presume most people do in software development.
>
> For the software I develop we have what is called a "live" branch, which is the code that is in active use by our customers. This branch corresponds to the stable branch we're trying to achieve, and it only gets critical bug fixes until the next major update which includes new features and/or major adjustments as well as non-critical bug fixes. We also have a testing branch, which includes the latest pre-release code for the next major update. This code is running on a VM and is tested by our customers (and the developers), under conditions similar to "live". There's also a common "dev" branch for the code which is in development but not yet ready for testing. This branch corresponds to the Dev (Master) Branch, The master branch gets updated from individual forks owned by each developer. Coordination among developers is essential to prevent duplications and major conflicts.
>
> So in essence we're following a similar model to the Debian model of (Master Dev) which is "unstable " => Pre-release Testing => Stable.
>
> It works great, and I see no way to remove any of the branches without seriously compromising the end result.
>
> For example, we can't go directly from Dev to Stable, that would be like committing suicide. We can't use testing for dev updates, it's too destabilizing and we'd never get a properly tested stable release out unless all development updates were halted for a long period of time, but then the individual forks would pile up with major changes that would be very difficult to sort out when merged all back together.
>
> We need 3 common branches, and I just don't see a way out of that.
>
> BTW, I'm using Mercurial which has many similarities to Git. Unfortunately I don't know my way around Git very well at this time.
>

So distro's versioning system is good for a programming language because you use it successfully in your software which isn't a programming language (and we also don't know according to which goal it is successful) ?

By the way, debian testing is not what you think it is : http://www.debian.org/devel/testing.en.html
December 16, 2012
On Sunday, 16 December 2012 at 07:39:09 UTC, deadalnix wrote:
> The compiler source code is probably what we have that look like the most as a spec right now.

Unfortunately that is likely the case. I hope we can all agree that the specification should be managed better, but it's a much lesser problem at the moment than what we're trying to solve in here.

I think once we can establish a process for development testing and release, the other problem areas will stand out a lot more clearly for elimination.

--rt
December 16, 2012
On Sunday, 16 December 2012 at 08:52:24 UTC, deadalnix wrote:
>
> So distro's versioning system is good for a programming language because you use it successfully in your software which isn't a programming language (and we also don't know according to which goal it is successful) ?

Let's not get different things mixed together.

There is a compiler, which is software. There is a language, but it is not software, it's the specification that the compiler implements.

It does not matter how branches are versioned, what matters is how they move from a highly unstable state towards an increasingly stable state until it is released in stable form for the end-user to use.

I will agree with you that there are unique challenges for a compiler, however we're not really talking about a compiler specifically at this stage, we're talking about establishing a way of moving source code from an unstable form into a stable form. What the compiler needs to achieve is a totally different concept, which is unfortunately not well documented. There is the current language specification, which is improperly managed as I pointed out in a previous post, and there needs to be certain guidelines set for the compiler to follow that are not a part of the language specification, but we're straying way off course at this point - those problem areas will have to be dealt with later, otherwise absolutely nothing at all will get done. There's just too many things to fix up around here, so we have to pick and chose very carefully what to deal with first before moving on to the next problem.

> By the way, debian testing is not what you think it is : http://www.debian.org/devel/testing.en.html

I think that I do know what Debian testing is. I do understand that the Debian distro is made up out of individual packages, but these packages can be generalized to what goes on when software is developed. For example, new features = new packages, code modifications = updated packages. When you distill things down to a process level, the payload managed by the process no longer matters so much.

--rt
December 16, 2012
On 12/16/2012 08:35 AM, deadalnix wrote:
> On Sunday, 16 December 2012 at 02:03:34 UTC, Jesse Phillips wrote:
>> You don't need to repeat your self, you need to expand on your points. Joseph
>> has already requested that you give specifics of your objection, you have
>> explained why the situation is different but not what needs to be different.
>
> This is completely backward, but I'll do it anyway. But first, let me explain
> why it is backward.
>
> You are using distro's versionning system as a base of reflexion. But such
> system is made to achieve different goal than a programming language. I
> shouldn't be here explaining why this is wrong, you should be here explaining me
> why it can be applied anyway.

And once again, you're failing to address the specifics of my proposal, simply saying "A distro and a programming language have different requirements."

Because while some of my proposals were inspired by some of the ways in which Ubuntu manages its releases, and share some of the same terminology, _they are not the same_.  In fact the only thing that it really shares with Ubuntu is the idea that the support and maintenance periods for long-term "stable" versions should overlap so that users who require that stable base have adequate time to upgrade.

That's useful for _any_ software no matter what the purpose.

So once again I'd ask you to engage with the specifics of my proposal -- because from what I've read so far, it seems like the _only_ source of your objections is the use of the words "Ubuntu" and "Long-Term Support", and that if I'd written the same proposal without those words, you'd have given a different response.
December 16, 2012
On 12/15/2012 09:39 PM, deadalnix wrote:
> Can we drop the LTS name ? It reminds me of ubuntu, and I clearly hope that
> people promoting that idea don't plan to reproduce ubuntu's scheme :
>   - it is not suitable for a programming language (as stated 3 time now, so just
> read before why I won't repeat it).
>   - ubuntu is notoriously unstable.

Call them "stable release cycles" if you like, which is what they are intended to be.  It's just that "long-term support" actually conveys quite well what _users_ can expect using these versions.

By the way, no one has proposed "using Ubuntu's scheme".  I made a proposal that drew on a number of ideas inspired by Ubuntu's release model, including terminology, but the actual detail was quite different and was tailored to my perceived requirements of D, not an operating system.

So, once again, I'd appreciate your response to those details, rather than your perception that I'm proposing "using Ubuntu's scheme".
December 16, 2012
On 12/16/12 6:15 AM, Joseph Rushton Wakeling wrote:
> On 12/15/2012 09:39 PM, deadalnix wrote:
>> Can we drop the LTS name ? It reminds me of ubuntu, and I clearly hope
>> that
>> people promoting that idea don't plan to reproduce ubuntu's scheme :
>> - it is not suitable for a programming language (as stated 3 time now,
>> so just
>> read before why I won't repeat it).
>> - ubuntu is notoriously unstable.
>
> Call them "stable release cycles" if you like, which is what they are
> intended to be.

Just one tidbit of information: I talked to Walter and we want to build into the process the ability to modify any particular release. (One possibility is to do so as part of paid support for large corporate users.) That means there needs to be one branch per release.

Andrei


December 16, 2012
On 12/16/2012 04:05 PM, Andrei Alexandrescu wrote:
> Just one tidbit of information: I talked to Walter and we want to build into the
> process the ability to modify any particular release. (One possibility is to do
> so as part of paid support for large corporate users.) That means there needs to
> be one branch per release.

Can you expand on the requirements/goals there a bit?  Would be useful to have a good sense of what kind of modifications you have in mind.

I don't think anything in what I've proposed (elsewhere in this thread, I'm afraid I haven't written it up on the wiki yet...) is incompatible with the notion of one branch per release.