[Kst] Updated Release Schedule

[George Staikos]

On Thursday 28 October 2004 12:48, Barth Netterfield wrote:
> On October 28, 2004 12:07 pm, George Staikos wrote:
> > It's time to update the release schedule for Kst 1.0.0 :)
> >
> > Due to unforeseen circumstances (bugs), I can't get the last few i18n
> > changes in by tomorrow so we need to push the string freeze to perhaps
> > Monday.  That means we can release 1.0.0 ~November 9th.  If all goes
> > well, I'll branch CVS on Nov 2 or 3.  We'll have a kst_1_0_branch and
> > eventually a kst_1_0_0_release tag.  I propose at this point that we send
> > all fixes to the mailing list with "Subject: [PATCH] fix xxxx" for review
> > so that we have a relatively stable 1.0.0 release.
>
> You mean once we branch (Monday)....  So you are volunteering to review the
> patches, and commit them?

  The typical mechanism (like the one used in KDE) is that you mail the patch 
to the list and don't commit until at least one other developer reads the 
patch and agrees with it.  Then you're free to commit it.

> Also, I, at least, will need detailed instructions on how to make a
> patch....

   cvs diff -u3p filenames... >myfix.patch

> > No code should go into HEAD.  I'll
> > forward port all of the fixes when we open HEAD for new development
> > again.
> >
> > Meanwhile, I think we should keep HEAD frozen for a while and work on
> > filling out the testcases and adding a more robust regression testing
> > system (more to come on this later).
>
> A lot of features have been added since Rick left.  Can we add
> documentation updates to the list of things to do during HEAD freeze? or is
> that already too late? If we update the English docs, do the
> un-re-translated docs go forward, or get dumped?  How does that all work.

   We have to do that before i18n freeze.  I was thinking about this too, but 
I really don't know if we can do it in time.  Is it worth holding back?

> > HEAD:
> > 	- for upcoming x.y.0 releases
> > 	- if y != 0, then binary incompatible commits are not allowed for public
> > interfaces of any sort
>
> Said another way, if (we need a BIC) {y==0; x++;}

   Yes :)

> > The next releases will be 1.0.1 in BRANCH, and 1.1.0 in HEAD.  I think we
> > should target mid-December for 1.1.0.  1.0.x releases can be very rapid.
> > Just tell me we need a new release with the bugfixes in the branch and I
> > can make it.
> >
> > HFI should only be using a branch.
>
> does this include an x.y.0?

  Well it will include 1.0.0 but only "instantaneously" as it will include 
patches thereafter.  We have the special tag for them too, though...

> > If any project (such as HFI) needs features rapidly, a branch of the
> > stable branch of Kst should be made to add the features.  Once complete,
> > they can be merged into HEAD.  (Hint: use tags to make your life easier)
> >
> > How does all of this sound?
>
> Good.  As long as the release name doesn't drive what we release....

  Fine with me. :)

-- 
George Staikos
KDE Developer				http://www.kde.org/
Staikos Computing Services Inc.		http://www.staikos.net/