I didn't mean to evince quite such a long thread as this!
Just to reinforce a couple of points here:
On 9/16/05, Alan Horkan <horkana@...44...> wrote:
On Fri, 16 Sep 2005, Ben Fowler wrote:
From: Ben Fowler <ben.the.mole@...400...> On 9/16/05, Alexandre Prokoudine <alexandre.prokoudine@...400...> wrote:
On 9/16/05, Ben Fowler <ben.the.mole@...400...> wrote:
Principally, _any_ pre-1.0 release should be considered as buggy.
We all like Inkscape and are enthusiastic about it but overselling it is counterproductive. ... . We dont need to make big claims about Inkscape, if we can get them to try it users should quickly realise for themselves it is pretty good.
I think the current 'blurb' is right: Inkscape is pre-1.0, but early adopters are using it for real work.
Yes, but we have end users using Inkscape for their regular work.
The reality is distributions are shipping Inkscape and users are expecting a level of stability more than developers expect. There is also no way distributions can keep up with the fast releases coming from inkscape as they are stuck on a 6 month/yearly cycle.
If this is a major problem, then we switch to an even/odd system and urge packagers to only pass downstream the even ones, or we do once or twice a year a stable release specifically for packagers, This might be too much work until after 1.0, by which time the problems will have changed anyway!
In the long term I think it would be good to have a stripped down stable supported release of inkscape maybe every six months or once a year to avoid the distributions shipping something which makes Inkscape look bad.
I agree.
They do not want regressions, and (to repeat) are entitled to have their views concerning features listened to.
Listen to the users. Say thank you to them for making the effort to provide us with feedback. Explain the limitations, manage their expectations and get to the enhancements when we can. If they know not to expect too much they wont be disappointed. If we dont do this we allow a predictable problem to happen and users will expect as much as they expect from fully supported commercial software.
I am not sure that users want to be managed, but the 'ear'y adopters' should be treated as full partners so far as directing the goes.
I think that everything that we release should be as good as we can make it, and if something is forward looking (untested and could have showstopping bugs) then it should be labelled as -HEAD dr or possibly alpha.
People are already treating Inkscape like it is a stable product even if it is in fact a fast moving alpha/beta stage project. Something should be done to accomodate or compensate for that perception.
My suggestion is to accommodate it by having at all times a stable branch and/or occasionally having bug fix only releases - 'No new features' - to prove that we mean to keep the count of outstanding issues controlled.
This is why I suggest that from a developer's point of view, we either need to be able to slipstream older bug fixes (my thaw policy as outlined above) or have protected releases when we only do bug fixes. Obviously the latter might be ruled out if you felt it was anathema, unnecessary pre-0.1 or not possible owing to the large number of enhancements going through.
I'm not going to get into specifics but I think this discussion reveals a problem we are aware of on some level and needs to be managed.
This is where I expect Bryce to step in without some wise words, to crystalize the situation and suggest a workable plan to help manage it.
A chunk of the 'Roadmap' page on the wiki seems to be missing.
See http://wiki.inkscape.org/cgi-bin/wiki.pl?CreatingDists the Feature Freeze section.
Ben