releasing inplications

[Casper Boemann]

On Sunday 13 March 2005 14:54, Boudewijn Rempt wrote:
> Those are not what I see as the big advantage of a release: having a
> release transforms an application from being a playground to something
> real. We need that, or, more accurately, _I_ need that. Krita has to stop
> being a promise and grow up. The only way is through exposure to the big
> bad world. We'll get a lot flak for sure, because after all these years we
> still don't have a 16-bit/channel, cmm-enabled (okay, we've got that, but
> only rudimentary) Gimp killer with a side-order of real media painting. But
> if we don't do a release, we won't get there anyway.

Sure, and I wasn't saying that we shouldn't release. In fact I think wo should 
release often.

My qualm is the strictness off releasing as part of ko. They release to slowly 
for a developing application

> > On the minus side we have:
> > - half finished design that would undergo several changes in the next
> > many releases, meaning fileformat and plugin changes. Backwards
> > compatibillity would be an issue.
>
> Not for me. It's silly to expect an application to retain it's 1.0 plugin
> API when you need a release just to discover what people need in such an
> API. And the file format should be pretty stable. I've got slight qualms
> about our usage for user-readable identifier strings for color models,
> profiles etc., but I've already got some code to factor that out. That
> should be included in the release. From that moment, we can just keep on
> extending the current file format (which is pretty good).

Sure, but things like colorspace independence needs much fixing so almost the 
day after 1.0 we'd need to break the api. Just so that the users don't expect 
too much.

> > - releasing a bugfilled application - is that a reputation we want
>
> So, what we need to do is make a concerted effort to get the bugs out of
> the minimal featureset we want to support and forget everything else. We
> still have some fall-out from the autolayers merge; that must be repaired
> first. We haven't made the progress I had hoped, things appeared to be more
> broken than I thought -- wise lesson, never have an opinion on code you
> haven't worked with for a month, just eye-balling isn't enough -- and that
> has meant that some cool features couldn't be worked on.

Don't blaim the autolayer merge for everything. Many bugs existed beforehand. 
But sure it needed some work after the merge.

>
> > - bug reports that would be outdated almost before releasing
>
> I'm pretty good at keeping bugzilla in order. Leave that to me, it's the
> application maintainer's job anyway.
>
> > - having to spend time on bugfixes in a release version takes time away
> > from developing.
>
> We must get Krita more stable, even if it's only for our own developing
> pleasure. The current situation is really bad and detracts from my own
> development pleasure. A release will help with that.

I wasn't saying that bug report are bad, but if ko is only released once every 
half year, we would have moved a long way, and changed the application. So 
again if we could somehow release every month instead it would be much 
better.

> > - attracting developers - the more we are the less consensus.
>
> That's true... Maybe I should play the dictator more often :-). In any
> case, having too many developers would be an embarrasment of riches -- I
> wouldn't mind that, but I'm a natural born glutton. But once there's a
> release out, people can work on plugins. Almost everything can be a plugin:
> our tools are plugins, our color models are plugins, the filters are (of
> course) plugins and lots of the UI is encapsulated in plugins, too. New
> scaling/transforming code should be done as plugins, too, and most new UI
> inventions (palettes, other resources), too. Plugins are great because they
> parallellize development.

BUT, we need to fix colorspace independance before any more work is done on 
filters tools etc. At the moment we are darting out the wrong way, with much 
of the code needing to be refactored.

>
> > So for me the deciding point is what the KOffice team says about us
> > releasing a "preview" as part of 1.4 without all the obligations of a
> > true release.
>
> That would be an option, but in practice, users would have a hard time
> perceiving the difference. A modest 1.0 release would be sufficient for me.
probably true, which is way I don't think we should release as part of ko but 
as an addon. And update/release often.

> > Otherwise I would prefer a simultaneous release, but not a true part of
> > KO.
> >
> > Another point is when the next ko release is scheduled.
>
> David Faure has mailed a release schedule, and that's one I intend to
> follow. We have until April 11 to add features, until May 23 to fix bugs
> and until June 7 to fix critical bugs. We must release with KOffice 1.4. I
> for one would find it hard to sustain interest myself if we didn't.
I know. I was thinking about the release after that. To have something to 
shoot for as the point where our rapid releases should become more stable 
(and part of official ko packages)

So release WITH ko 1.4 but not as PART OF.
-- 
best regards / venlig hilsen
Casper Boemann