D 1.076 and 2.061 release

[Pierre Rouleau]

On 13-01-07 9:12 AM, Matthew Caron wrote:
> On 01/07/2013 08:09 AM, Pierre Rouleau wrote:
>> It would be nice to have bug fixes separated from new feature
>> introductions by having major and minor releases and branches for these
>> releases.  Contributors of a release could backport bug fix in the
>> release they use if that was required by their project using the now old
>> compiler version.
>>
>> Of course I realize that this means more overall work, more people,
>> someone or a set of people in charge of release management, etc...
>
> I also think that you'd be hard-pressed to find anyone who does
> development like that, proprietary or open source. It's not uncommon to
> have bugfix only releases, but having a new features release that
> doesn't fix any bugs is, in my experience, unheard of.

I agree that feature releases mostly also contain bug fixes. I should 
have said, and I was thinking about proposing a process where minor 
releases that would only include bug fixes, and where major releases 
would mainly introduce new features but would also include some bug fixes.

At work this is exactly what we do. And today, at work, I was just in a 
meeting evaluating bugs to identify bugs that will be fixed in a release 
of our product that will only contain bug fixes.  The fixes that are 
selected where selected based on their severity, the impact they have on 
end-users and the time it takes to fix them.

And maybe an alpha process suggested by Jonathan M. Davis is a better idea.

>
> Also, I'd be STRONGLY against it, because I have a fix bugs first
> mentality, and if you find a bug while implementing a new feature, it
> should be fixed.
>

In my work I also have a bug-fix first mentality and I push for that 
everyday. I strongly agree with that. All I was suggesting (or checking 
if this is the way this group handles it) is whether bug fixes are 
isolated from feature implementations (and I assume they are since they 
are separate Bugzilla tickets).

And at work, when a new feature is implemented and a bug is found during 
the process of developing that feature the first thing that is done is 
to create a _separate_ bug report ticket (separate from the ticket that 
request the introduction of the new feature or enhancement) to identify 
the presence of that bug if that bug affects release code.  The releases 
the bug affects are identified and typically within a week, the bug is 
"scrubbed" in a meeting where people with different roles attend.  The 
priority and severity of the bug is discussed, and the release version 
for the fix is identified in a forecast. Developer(s) have to estimate 
the time it will take to fix the bug (as is done for every ticket in our 
bug tracking system (bug fix, feature implementation, enhancement, 
etc...).  A test case is also created for the bug since it was an escape 
from the test plan/integration test/unit test side of things.

The bug is fixed, regression tested and the new feature is implemented 
on top of the bug fix.  The sequence of events may differ depending on 
how we want to handle things with the VCS we use and the moment of the 
event respective to the product release plan.

I am not suggesting to not fix a bug found when a new feature is 
introduced. I was trying to propose something that would help 
predictability and stability.

Now I understand that I am comparing a commercial product development 
with an open source project here.  But I am also comparing what a user 
*sees* from other projects that are used where I work; the PR part, the 
marketing material that help sells the product to people.  When I look 
at Python and Erlang for instance, those two projects seem, I say seem 
(from the user's perspective) to provide more information to the user's 
base in terms of those two criteria of predictability and stability 
simply because of the various documents provided and release strategies 
one can see from the evolution of their projects.

It possibly is only a matter of perception and Public Relations but D2 
first release was done June 17, 2007 which is over 5 years and six 
months ago.  I see nothing in the release version number that gives any 
outsider a vision of the stability of D2 or it's evolution 
milestone-wise.  The first release number was D 2.000 and we are 66 
months later at version 2.061. That's about a release a month.  How can 
an outside user see the major milestones in those 5 years and a half?  I 
imagine that some of you guys remember what were the significant 
releases, you have been living with it for those last 66 months.  But 
how can you convince potential new users to use it in projects where 
manpower is also limited and continuous updates may not be possible? 
How can they see that its stabilizing? How many more releases may affect 
the development of products?  In June 2007 I was using Python 2.5.1, 
Python 2.7.3 and 3.3.0 are the two official releases now.  All of these 
versions have had bug fix (and security) releases independently of the 
other ones. These versions had reached a point of finality. I have not 
yet switched to Python 3.3 for production code but have upgraded from 
2.5 to 2.6 and 2.7.   Each time we looked at the major changes prior to 
the upgrades to identify the amount of work required in order to 
schedule it in the work flow.  I have also upgraded from minor to minor 
releases much quicker. We do the same for Erlang.  To be able to use D 
at work for product development, I will have to be able to do the same.

And now I understand that D1 is no longer officially supported. If I 
understand properly D1 first release was 6 years ago.  Lets assume I 
would have started a product development with it say 2 years ago because 
it was deemed relatively stable then.  And now I want to support 64-bit 
Windows and my customers are starting to ask for Windows-8 support.  Or 
some other things gets in the way (a bug somewhere, Windows 9 getting 
released sooner because Windows 8 is not as popular as Microsoft would 
have hoped.) What would be my alternatives? Port all the code to D2?  Is 
this what will happen to D2? I'd like to know before I commit people and 
convince others.

At the moment what I see of the current state is that if I am 
interested, I should join the developers group and use D for fun and 
expertise.  I just hope that I am missing something (beside the fun and 
expertise) that could help convince myself and others that I could 
depend on D for product development at work.

BTW, the proposal from Andrei to implement a "pre-approved" 
non-prioritized enhancement request mechanism seems a very good idea and 
a step in the good direction IMHO (from the outside).





-- 
/Pierre Rouleau