Context Refactoring

on Wed Oct 10 2007, "Emmanuel Blot"
<manu.blot-AT-gmail.com> wrote:

>> so if you release now, and then do a bugfix release
by changing the
>> context like cmlenz suggests, who would care? and
then release
>> something further developped with maybe an idea of
cboos in it
>> discussed?
>
> The developers team use a version numbering scheme that
carries some meaning:
> 0.11.1 and subsequent 0.11.x releases should not break
APIs that will
> be available in 0.11. This scheme won't be changed for
the sake of
> releasing earlier.
>
> 0.11 needs to be released, everyone's expecting it, but
it needs to be
> a well defined object.

I still think it's possible to release a well-defined
Trac-0.11 soon,
and without fixing *all* the design problems that you know
about
first.  I suggested a way that could happen in
http://article.gmane.org/gmane.com
p.version-control.subversion.trac.devel/2600
but I guess that post was either not understood or
considered
irrelevant, because nobody replied.

> If you don't care about the numbering scheme, you can
check out the
> code from the trunk.

And that has serious problems in a component-based world
like you have
created.  Plugins generally don't work with "the
trunk" because it's a
moving target.  The longer 0.11 continues moving before a
release, the
more hostile the environment becomes for plugin authors.

> As a user, I do care about the version numbering.
> Users are already confused about which plugin they can
use with a
> given release of Trac. I can't imagine the support
nightmare
> (MailingList and tickets) if the APIs vary over bug fix
releases...

Agreed.  That would be a reason to release sooner with some
of the new
and less-stable APIs still in the code but essentially
removed from
Trac's public interface.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-cons
ulting.com


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Trac Development" group.
To post to this group, send email to trac-devgooglegroups.com
To unsubscribe from this group, send email to
trac-dev-unsubscribegooglegroups.com
For more options, visit this group at http://
groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

on Wed Oct 10 2007, Noah Kantrowitz
<kantrn-AT-rpi.edu> wrote:

>> so if you release now, and then do a bugfix release
by changing the
>> context like cmlenz suggests, who would care? and
then release
>> something further developped with maybe an idea of
cboos in it
>> discussed?
>
> We do not want to declare some of these APIs as
available for public  
> consumption if they are going to break or be removed
very shortly.  

Suggestion: so don't declare those APIs available, and keep
working on
them until you're ready to release them.  If they're in the
code,
under the covers, they won't hurt anybody as long as they
work as
currently expected.

> This is why we will not release until the devs are all
happy with  
> this new system.

In my opinion the cost of further release delays is high,
and paying
it is unnecessary.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-cons
ulting.com


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Trac Development" group.
To post to this group, send email to trac-devgooglegroups.com
To unsubscribe from this group, send email to
trac-dev-unsubscribegooglegroups.com
For more options, visit this group at http://
groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

David Abrahams wrote:
> on Wed Oct 10 2007, Noah Kantrowitz
<kantrn-AT-rpi.edu> wrote:
>
>   
>>> so if you release now, and then do a bugfix
release by changing the
>>> context like cmlenz suggests, who would care?
and then release
>>> something further developped with maybe an idea
of cboos in it
>>> discussed?
>>>       
>> We do not want to declare some of these APIs as
available for public  
>> consumption if they are going to break or be
removed very shortly.  
>>     
>
> Suggestion: so don't declare those APIs available, and
keep working on
> them until you're ready to release them.  If they're in
the code,
> under the covers, they won't hurt anybody as long as
they work as
> currently expected.
>
>   
The reason this API is so contested is that isn't possible.
It is used
quite literally everywhere.

--Noah

Am 17.10.2007 um 19:34 schrieb David Abrahams:
> on Wed Oct 10 2007, Noah Kantrowitz
<kantrn-AT-rpi.edu> wrote:
>
>>> so if you release now, and then do a bugfix
release by changing the
>>> context like cmlenz suggests, who would care?
and then release
>>> something further developped with maybe an idea
of cboos in it
>>> discussed?
>>
>> We do not want to declare some of these APIs as
available for public
>> consumption if they are going to break or be
removed very shortly.
>
> Suggestion: so don't declare those APIs available, and
keep working on
> them until you're ready to release them.  If they're in
the code,
> under the covers, they won't hurt anybody as long as
they work as
> currently expected.

In general I'd agree, however we're talking about the
Context API,  
which is used *all over the place*, with some other APIs
(timeline)  
building on it. There's no way to simply hide this API and
say it's  
not ready for prime time. It *needs* to be fixed before a
release.

If we were talking about some optional, obscure API used
somewhere in  
some part of the internal Trac code, things would be
different. But  
we're really talking about an API that has had much more
impact to  
many more places of the code than it should have had, IMHO.

>> This is why we will not release until the devs are
all happy with
>> this new system.
>
> In my opinion the cost of further release delays is
high, and paying
> it is unnecessary.

The cost is high, but I think paying it *is* necessary,
otherwise the  
follow-up cost will be tremendous.

This is why I wrote a "What's gone wrong..."
thread. Ideally, we  
shouldn't even gotten ourselves into this situation, but
we're here,  
and we need to fix it.

Cheers,
Chris
--
Christopher Lenz
   cmlenz at gmx.de
   http://www.cmlenz.net/


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Trac Development" group.
To post to this group, send email to trac-devgooglegroups.com
To unsubscribe from this group, send email to
trac-dev-unsubscribegooglegroups.com
For more options, visit this group at http://
groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

on Wed Oct 17 2007, Christopher Lenz
<cmlenz-AT-gmx.de> wrote:

> Am 17.10.2007 um 19:34 schrieb David Abrahams:
>> on Wed Oct 10 2007, Noah Kantrowitz
<kantrn-AT-rpi.edu> wrote:
>>
>>>> so if you release now, and then do a bugfix
release by changing the
>>>> context like cmlenz suggests, who would
care? and then release
>>>> something further developped with maybe an
idea of cboos in it
>>>> discussed?
>>>
>>> We do not want to declare some of these APIs as
available for public
>>> consumption if they are going to break or be
removed very shortly.
>>
>> Suggestion: so don't declare those APIs available,
and keep working on
>> them until you're ready to release them.  If
they're in the code,
>> under the covers, they won't hurt anybody as long
as they work as
>> currently expected.
>
> In general I'd agree, however we're talking about the
Context API,  
> which is used *all over the place*, with some other
APIs (timeline)  
> building on it. There's no way to simply hide this API
and say it's  
> not ready for prime time. It *needs* to be fixed before
a release.

Can you make the API (temporarily) backward-compatible with
0.10.x,
and then just document it as being the 0.10.x API, even if
various
parts of Trac's own code (and even some existing plugins)
are reaching
in and using the partially-baked newer bits?

> If we were talking about some optional, obscure API
used somewhere in  
> some part of the internal Trac code, things would be
different. But  
> we're really talking about an API that has had much
more impact to  
> many more places of the code than it should have had,
IMHO.

Hm.

>>> This is why we will not release until the devs
are all happy with
>>> this new system.
>>
>> In my opinion the cost of further release delays is
high, and paying
>> it is unnecessary.
>
> The cost is high, but I think paying it *is* necessary,
otherwise the  
> follow-up cost will be tremendous.
>
> This is why I wrote a "What's gone wrong..."
thread. Ideally, we  
> shouldn't even gotten ourselves into this situation,
but we're here,  
> and we need to fix it.

Agreed.  It's just a question of how much needs to be fixed
before
people can have another release target to shoot at.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-cons
ulting.com


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Trac Development" group.
To post to this group, send email to trac-devgooglegroups.com
To unsubscribe from this group, send email to
trac-dev-unsubscribegooglegroups.com
For more options, visit this group at http://
groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

On 17 Okt., 19:55, Christopher Lenz <cml...gmx.de> wrote:
> Am 17.10.2007 um 19:34 schrieb David Abrahams:
>
> > on Wed Oct 10 2007, Noah Kantrowitz
<kantrn-AT-rpi.edu> wrote:
>
> >>> so if you release now, and then do a
bugfix release by changing the
> >>> context like cmlenz suggests, who would
care? and then release
> >>> something further developped with maybe an
idea of cboos in it
> >>> discussed?
>
> >> We do not want to declare some of these APIs
as available for public
> >> consumption if they are going to break or be
removed very shortly.
>
> > Suggestion: so don't declare those APIs available,
and keep working on
> > them until you're ready to release them.  If
they're in the code,
> > under the covers, they won't hurt anybody as long
as they work as
> > currently expected.
>
> In general I'd agree, however we're talking about the
Context API,  
> which is used *all over the place*, with some other
APIs (timeline)  
> building on it. There's no way to simply hide this API
and say it's  
> not ready for prime time. It *needs* to be fixed before
a release.
>

why? how all these currently running 0.11 installations
using 0.11 api
compatible plugins will handle such a change? why not just
tag and
release cboos context changes as new version 0.12? i think
calling
0.11 calling "release" is the wrong word - as it
is already out.

tagging what you have to guarantee some managed change cycle
seems not
a bad strategy.

rupert.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Trac Development" group.
To post to this group, send email to trac-devgooglegroups.com
To unsubscribe from this group, send email to
trac-dev-unsubscribegooglegroups.com
For more options, visit this group at http://
groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---