incubator-jspwiki-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Terry Steichen <te...@net-frame.com>
Subject Re: Change Management Suggestion
Date Thu, 03 Jan 2008 19:43:02 GMT
I hope I'm not coming across as negative or petty.  As explained below, 
I think there's a real issue here that we would do well to address now.

Janne Jalkanen wrote:
> We have testers?  That's news to me...
>
> The thing is - we can't force anyone to test anything.  So it really
> all comes down to volunteers.  We can make policies and plans, but
> unless we have people executing them, they don't matter.
>   
I didn't suggest that you have forced or should try to force anything.  
Perhaps the problem is me - that after all this time, I don't properly 
understand what the adjective 'stable' really implies.  Certainly, it's 
very desirable to be constantly evolving new features; that's what the 
2.5.xx series was for.  Yet, I think we would all agree that we also 
need a dependable version that people can use immediately, which is, I 
assume(d) is what 2.4.xx was all about.

The issue (and from reading your comment, I do think it is an issue) is 
what can the user of a stable version expect from the next stable 
(non-major) version?  Certainly, at a minimum, what we should do is 
define what parts of the original stable version 'break' when shifting 
to the new version (rather than have them pop up after release about an 
issue which has been known for months).  Ideally, this would be 
accompanied by a smooth and simple upgrade of some sort.  I mean, what's 
the point of having those who want to immediately use the product be 
directed to a stable version which is more or less guaranteed not to be 
compatible with the next stable version?
> I have a set of plugins I do test against (and they are working nicely
> in 2.6 and 2.4).  I can't say anything about anyone else.
>   
Excellent point.  So, at least as far as those particular plugins are 
concerned, testing for 2.4.xx was done (at least by you).  Why not 
include things like filters as well?  And why not make these part of a 
standard set of compatibility tests?

> The thing is, most people don't care until they realize that there's a
> new stable out there.  Then they try it, and then they see things
> broken.  This could take months, if they have no problems with the
> existing stable.  And we have no way of knowing what they are doing
> with the software, so we can't even check for it.
>   
I do understand and appreciate the problem you mention above.  However, 
I think it's a reasonable thing to announce a new stable version on the 
discussion list and leave it up to users to upgrade or take their 
chances later.

> Jumping from 2.4 to 2.6 means that new stuff gets added, and
> compatibility MAY be broken in minor ways (the PageFilter one is a
> minor incompatibility, as filters can be fixed in about two minutes as
> there is no behaviour change.  
>   
Well, that's part of my question: are the incompatibilities all minor, 
and if so, how do you know that (if there's no effort made to map 2.4 
into 2.6)?  Even more fundamentally, what are all the known 
incompatibilities?  And, as for the two minute estimate, that assumes 
you know about the incompatibility; tracing down the bizzare behavior 
that might result can, as you know, consume a lot more time than that.

> Jumping from 2.x to 3.0 means that compatibility WILL be broken,
> unless by miraculous chance it works.
>   
I understand that in making a major version change, some 
incompatibilities are expected and reasonable.  (I do wonder, however, 
if we will continue parallel development paths as we did in 2.4.xx and 
2.5.xx? See following comment)

> Unfortunately, we don't have a systematic way of checking
> against compatibility.  This is something I would really like someone
> to pick up.
>   
Yes, I think that's the bottom line.  While I do understand and 
appreciate the reasoning between the 2.4xx/2.5xx parallel development, I 
now wonder if that doesn't make compatibility extraordinarily 
difficult.  Yet, we also want to continue feature development.  I don't 
know how to best reconcile these objectives.


Mime
View raw message