Am 16.06.2012, 06:25 Uhr, schrieb Scott Kitterman <[email protected]>:
On Friday, June 15, 2012 01:05:44 PM Sebastian Kügler wrote:
As an example, Frameworks could release updates every 2 months, while
our
application collection is updated monthly. New iterations of the
workspaces
come every four months. (These numbers are completely arbitrary, and
here
only for illustration purpose!)
More specifically for the Workspaces, we would like to release all
workspaces at the same time.
This model would
* Allow components to skip releases if they need to take a longer
development cycle
* encourage developers to have an always releasable master
* put more emphasis on continuous integration and other automated
testing
If I am reading your proposal correctly, I don't see anything about a
stable
supported branch to which only bug fixes were added? Where is the
post-release
support model in this?
Perhaps there should be a standard interval (maybe even 6 months) for
all of
KDE SC to have one temporally aligned set of releases to provide
post-release
bugfix support for? That would allow the more rapid, less synchronized
process
you're advocating, but still give a supported target for distros to aim
at.
I don't know whether this is in scope of this discussion, but as developer
imho we've atm. an issue with release testing.
While there's currently this nice beta testing offensive passing
relatively much feedback, the current model makes us develop a new version
for half a year, then have a beta phase only a minority of users
participate and then dump the new version as "stable" blob.
Therefore i'd -personally- rather use a component wise three branch model:
current/next/development
CURRENT --------------------
Target audience:
"I know where to turn on my computer"
Commit policy:
* Bug fixes ONLY which are in control and are tested and guaranteed to fix
bugs.
* NO new features.
* NO experimental fixes.
* NO new strings.
Release policy:
irregular. Whenever developers think it's required to pass a bugfix
release downstream.
No bloody "patchday"
---------------------------------------
NEXT ----------------------------
Target audience:
"Crashes I fear not, for I have a bash!"
Commit policy:
* Reasonably reliable and finished features
* FINAL API!
* Experimental bug fixes ("I'm quite sure this is gonna fix it, could be
wrong and have side effects though")
* New strings simply appear untranslated - you've a bash open, you can
handle this
* NO "NEXT" upstream requirements (ie. eg. Dolphin NEXT must NOT rely on
KIO NEXT)
Release policy:
Like every two weeks to keep advanced and interested users up-to-date
Of course you can skip releases if there's nothing new to see.
---------------------------------------
DEVELOPMENT ------------
Target audience:
"I produce the crash" ie. component and core developers or whoever thinks
s/he is
Commit policy:
* in production features
* "it compiles" (usually...)
* ideally code is also reviewed, but that can be component internal policy
* NO "DEVELOPMENT" upstream requirements ("moving target" issue)
Release policy:
git fetch; git rebase
---------------------------------------
In an interval that mostly distros will care about (like every 6 month or
so) NEXT turns into CURRENT, CURRENT turns into "unmaintained"
At some point ahead (4-6 weeks?), NEXT should rather be frozen for new
features and focus on becoming in shape for turning into CURRENT (when
it's also i18n'ized)
I would wish that every distro offers CURRENT and NEXT and that
distros/variants targeting a more savvy audience would make NEXT default
and CURRENT option and others promote the existence of NEXT so that their
advanced users can find and easily select it as replacement.
Cheers,
Thomas
_______________________________________________
release-team mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/release-team
