[ jEdit-devel ] RFC "Regular stable releases / nightlies / 3 alphas 3 betas 3 RCs"

[Daniel B. <ma...@da...>]

Hi all,

I followed the discussion about the realease management process and IMHO
I can give my 50cents about it. I'm in the TYPO3 community since 2002
and in the Linux Ubuntu community since 2005 -- and like to propose how
it would be cool also for jEdit. Have a look at
http://wiki.typo3.org/Category:ReleaseNotes

example for TYPO3 (where it works best IMHO): Version 4.0.0 at
2006-04-07, Version 4.1.0 at 2007-03-06, Version 4.2.0 at 2008-04-23,
  Version 4.3.0 at 2009-11-30, Version 4.4.0 at 2010-06-22

Now what I propose for jEdit:
--------------------------
- "Regular major release": one time a year a x.y.0 (for API-changes and
completely new features, support for 2 years)
- "Public 3 alphas": New features just in the alpha-phase (so that the
next major stable WILL be stable)
- "Public 3 betas": Make-ready the new features just in the beta-phase
(so that the next major stable WILL be stable)
- "Public 3 RCs": just bugfixes in the ReleaseCandidate-phase (so that
the next major stable WILL be stable)
- "Nightlies": The nightly .jar builds (for the SVN and git branches,
nightlies of the last 5 days)
- "Fast minor bugfix-releases": a x.y.z version (a minor release when
some bugs are fixed, NO new features (!) )
- "Plugins into Core": move into the jEdit core (a plugin what is in use
by many other plugins can be moved into the core)
--------------------------

This is much more than the current thing "releases and pre-releases",
but with Hudson it's not so hard to do that. So this gives some
advantages: 1. plugin authors know that a new feature can get into the
core one time a year, 2. everybody knows and "feels" that jEdit has 100%
stable features. 3. Plugins can easily tested with alphas, betas, RCs.

Greets!
Daniel

.......................................................
:: TEL    +49 (0)911 - 815 90 30
:: Daniel Brüßler - Emilienstr. 10 - 90489 Nürnberg


> Hi, Vampire
>
> Now about the need of pre-release;
>
> Note that I'm not saying to skip any broad-mass testing, but
> suggesting to change the way to be more easy and quick.
>
> Vampire wrote:
>   
>>>  Could you point the agreement as a link to ML archive?
>>>       
>> The link you wrote is already the correct one. Just search for "pre" and you
>> will see.
>>     
>
> Searching "pre" in those threads gives over 100 occurrences, and many
> are in discussion, not in agreement.
>
> Again, could you please point an exact post as the agreement which says
> we require pre-releases?
>
>
> FYI, I found a agreement to use a specific daily build for testing
> purpose, between Eric and me, which is almost same agreement on this
> thread what we are actually doing via the second announce from Alan.
> There seems no negative argument to this idea, at least for now.
>
> http://old.nabble.com/Re%3A-4.4.1--p27914207.html
> Eric wrote at Mar 16, 2010:
>   
>> (I wrote:)
>>     
>>> If the first motivation of having pre-release is just increasing testers
>>> of new features, I think it's enough if we announce a recommended
>>> version of daily build, possibly with additional installers manually
>>> built for that version, with appropriate warnings.
>>>       
>> Agreed. As I mentioned above, I would be willing to kick off manual builds ...
>>