[Kst] Updated Release Schedule

[Barth Netterfield]

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?

Also, I, at least, will need detailed instructions on how to make a 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.

> Beyond that, we will have two branches of Kst active.  Here are the commit
> rules:
>
> 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++;}

> 	- i18n() changes are allowed
> 	- new features
> 	- all bug fixes
> 	- all testing updates
> 	- all documentation updates
>
> BRANCH:
> 	- kst_x_y_branch
> 	- no i18n() changes allowed
> 	- no binary incompatible changes allowed
> 	- no new features allowed
> 	- appropriate and safe bug fixes
> 	- no doc changes
>
> 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?  

> 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....