Electronics & Programming

develissimo

Open Source electronics development and programming

  • You are not logged in.
  • Root
  • » PHP
  • » [PHP-DEV] [RFC] Release Process [RSS Feed]

#1 Nov. 23, 2010 09:33:18

Johannes S.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] [RFC] Release Process


Hi,

On Mon, 2010-11-22 at 23:21 -0200, Felipe Pena wrote:
> With the recent chaos in the way we begin and ended releases, we would
> like to propose a clean way to deal with releases and related decisions:

Thanks for preparing this. I have one change proposal:

With the proposed model it might, as you have illustrated, happen that
there are 5 versions being maintained.

As I mentioned multiple times on this list, on irc and other places I
like a Ubuntu-like model with two kinds of release which I, for the
purpose of this discussion, call "early access" (EA) and "long term
supported" (LTS) version.

At any given time only one EA may exist. When a new LTS version is being
released the previous LTS version enters security-only mode to give
users a transition period. Between every LTS version there are two EA
versions.

2011 2012 2013 2014 2015 2016
2017
| | | | | | | | | | | |
|
LTS1 +++++++++++++++++++++++++++++++++++++-----------D | | |
|
EA1 | | ++++++++++++D | | | | | | |
|
EA2 | | | | ++++++++++++D | | | | |
|
LTS2 | | | | | |
++++++++++++++++++++++++++++++++++++-----------D
EA3 | | | | | | | | ++++++++++++D
EA4 | | | | | | | | | |
++++++++++++D

The benefit is that developers and users who require a specific feature
get it early while distributors/hosters/software vendors/... have a safe
bet.

johannes


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#2 Nov. 23, 2010 10:07:55

Derick R.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] [RFC] Release Process


On Mon, 22 Nov 2010, Felipe Pena wrote:

> With the recent chaos in the way we begin and ended releases, we would
> like to propose a clean way to deal with releases and related decisions:

Really? I think you're blowing this all way out of proportion.

I don't mind a yearly release cycle, as we should get out more releases.
I don't mind a monthly release cycle for .z releases.

What however goes straight against this is:

* January
o Decisions which features or changes will be in the next
release

You don't decide on it, you just have to go with what we have.

All the rest you write in the RFC is basically already as we do it.

regards,
Derick

--http://derickrethans.nl|http://xdebug.orgLike Xdebug? Consider a donation:http://xdebug.org/donate.phptwitter: @derickr and @xdebug

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#3 Nov. 23, 2010 11:33:32

Ferenc K.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] [RFC] Release Process


On Tue, Nov 23, 2010 at 11:07 AM, Derick Rethans <der***@*hp.net> wrote:

> On Mon, 22 Nov 2010, Felipe Pena wrote:
>
> > With the recent chaos in the way we begin and ended releases, we would
> > like to propose a clean way to deal with releases and related decisions:
>
>
> Really? I think you're blowing this all way out of proportion.
>

Why do you think that?
I can see two reason:
1) you think that the current rules/policies/methods are good enough.
2) you think that these rules/policies/methods aren't important for the
quality of the release.

both seems wrong from the past experiences of new php major/major.minor
releases.
see my last email in the other thread


>
> I don't mind a yearly release cycle, as we should get out more releases.
> I don't mind a monthly release cycle for .z releases.
>
> What however goes straight against this is:
>
> * January
> o Decisions which features or changes will be in the next
> release
>
> You don't decide on it, you just have to go with what we have.
>

who decided that?


>
> All the rest you write in the RFC is basically already as we do it.
>

yeah, maybe, but they aren't written down, accepted and well-known rules, so
you can forgot/misunderstand/bend them. :/

Tyrael

Offline

#4 Nov. 23, 2010 14:01:43

Derick R.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] [RFC] Release Process


On Tue, 23 Nov 2010, Ferenc Kovacs wrote:

> > All the rest you write in the RFC is basically already as we do it.
>
> yeah, maybe, but they aren't written down, accepted and well-known rules, so
> you can forgot/misunderstand/bend them. :/

And I don't think that is a bad thing. It's good to be able to be
flexible.

Derick

--http://derickrethans.nl|http://xdebug.orgLike Xdebug? Consider a donation:http://xdebug.org/donate.phptwitter: @derickr and @xdebug

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#5 Nov. 23, 2010 14:12:09

Ferenc K.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] [RFC] Release Process


On Tue, Nov 23, 2010 at 2:59 PM, Derick Rethans <der***@*hp.net> wrote:

> On Tue, 23 Nov 2010, Ferenc Kovacs wrote:
>
> > > All the rest you write in the RFC is basically already as we do it.
> >
> > yeah, maybe, but they aren't written down, accepted and well-known rules,
> so
> > you can forgot/misunderstand/bend them. :/
>
> And I don't think that is a bad thing. It's good to be able to be
> flexible.
>
> Derick
>
>
Its good for you, but its bad for the people, who expect you to follow the
rules, you know, the vendors, developers, etc.

Tyrael

Offline

#6 Nov. 23, 2010 14:18:29

Matthew W.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] [RFC] Release Process


On 2010-11-23, Derick Rethans <der***@*hp.net> wrote:
> On Tue, 23 Nov 2010, Ferenc Kovacs wrote:
> > > All the rest you write in the RFC is basically already as we do it.
> >
> > yeah, maybe, but they aren't written down, accepted and well-known rules, so
> > you can forgot/misunderstand/bend them. :/
>
> And I don't think that is a bad thing. It's good to be able to be
> flexible.

A good artist is capable of great flexibility within the constraints of
their medium. In the case of software releases, you can still have
greate flexibility even with an existing release process. In many ways,
having the process defined helps bring about creative solutions -- "if I
want to get this in time for the release, what solution will work best?"

I used to love the ad hoc nature of "we'll release when it's ready."
However, having done quite a number of scheduled releases, I've found
that:

* Predictability motivates developers. "Release is in 3 months? Okay,
let's get rolling on this!"

* Knowing when the next release is coming also means that developers
are more comfortable if they're unable to make the deadline. "I can't
do it by this release, but I should have no trouble making the next."

* Less stressful for release managers. If the code isn't ready by the
deadline, it's not merged to the branch, plain and simple.

The status quo works great for those whom it serves. For everyone else,
it stinks. There's no transparency, which leads to disenfranchisement.

--
Matthew Weier O'Phinney
Project Lead | matt***@*end.com
Zend Framework |http://framework.zend.com/PGP key:http://framework.zend.com/zf-matthew-pgp-key.asc--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#7 Nov. 23, 2010 14:19:53

James B.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] [RFC] Release Process


Just a thought from a non-dev

Rules/policies/procedures/process should always be written down or recorded
somewhere, otherwise how do you know what they are? and how do you make sure
changes to those rules are known about?
Having a central place that every can reference (wiki) makes a ton of sense.

This doesn't mean they have to be inflexible. Flexibility is down to how those
rules etc are written.

this is fairly basic service management sort of stuff. (No i am not proposing
bringing in ITIL/CMMI would be sensible)

By having this sort of stuff in the wiki, you are making it easier for new
people to get up to speed and reduce the arguments over what the agreed method
of doing X is.

James


-----Original Message-----
From: i***@*yrael.hu On Behalf Of Ferenc Kovacs
Sent: 23 November 2010 14:10
To: Derick Rethans
Cc: Felipe Pena; internals
Subject: Re: Release Process

On Tue, Nov 23, 2010 at 2:59 PM, Derick Rethans <der***@*hp.net> wrote:

> On Tue, 23 Nov 2010, Ferenc Kovacs wrote:
>
> > > All the rest you write in the RFC is basically already as we do it.
> >
> > yeah, maybe, but they aren't written down, accepted and well-known rules,
> so
> > you can forgot/misunderstand/bend them. :/
>
> And I don't think that is a bad thing. It's good to be able to be
> flexible.
>
> Derick
>
>
Its good for you, but its bad for the people, who expect you to follow the
rules, you know, the vendors, developers, etc.

Tyrael


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#8 Nov. 23, 2010 14:32:05

James B.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] [RFC] Release Process


-----Original Message-----
From: Matthew Weier O'Phinney
Sent: 23 November 2010 14:18
To: intern***@*ists.php.net
Subject: Re: Release Process

On 2010-11-23, Derick Rethans <der***@*hp.net> wrote:
> On Tue, 23 Nov 2010, Ferenc Kovacs wrote:
> > > All the rest you write in the RFC is basically already as we do it.
> >
> > yeah, maybe, but they aren't written down, accepted and well-known rules, so
> > you can forgot/misunderstand/bend them. :/
>
> And I don't think that is a bad thing. It's good to be able to be
> flexible.

A good artist is capable of great flexibility within the constraints of
their medium. In the case of software releases, you can still have
greate flexibility even with an existing release process. In many ways,
having the process defined helps bring about creative solutions -- "if I
want to get this in time for the release, what solution will work best?"

I used to love the ad hoc nature of "we'll release when it's ready."
However, having done quite a number of scheduled releases, I've found
that:

* Predictability motivates developers. "Release is in 3 months? Okay,
let's get rolling on this!"

* Knowing when the next release is coming also means that developers
are more comfortable if they're unable to make the deadline. "I can't
do it by this release, but I should have no trouble making the next."

* Less stressful for release managers. If the code isn't ready by the
deadline, it's not merged to the branch, plain and simple.

The status quo works great for those whom it serves. For everyone else,
it stinks. There's no transparency, which leads to disenfranchisement.


--
Matthew Weier O'Phinney
Project Lead | matt***@*end.com
Zend Framework |http://framework.zend.com/PGP key:http://framework.zend.com/zf-matthew-pgp-key.asc+1

PHP is big/grown-up/widely-used enough now that "shipping is a feature"
It's gone beyond just being a beginners tool for knocking out basic web pages.
Enterprise (who-ever that is :-) now uses PHP and as such will want PHP to have
some degree of uniformity with release cycles and feature addition/removal so
that they can easily factor it in to their own deployment/upgrade plans etc.
While they dislike change (tongue in cheek), they dislike the unknown more.

Transparency also helps people get on board from both a developer perspective
and user one too. It gives little people the warm and fuzzy feeling because
they can at least understand how everything works/decisions are made even if
they aren't involved in them, and if they did want to get involved, they can
see what they have to do.

just my 2 cents.


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#9 Nov. 23, 2010 14:49:10

Derick R.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] [RFC] Release Process


On Tue, 23 Nov 2010, Matthew Weier O'Phinney wrote:

> The status quo works great for those whom it serves. For everyone else,
> it stinks. There's no transparency, which leads to disenfranchisement.

That's why my first reply said:

I don't mind a yearly release cycle, as we should get out more releases.
I don't mind a monthly release cycle for .z releases.

*that* is a good thing.

regards,
Derick

--http://derickrethans.nl|http://xdebug.orgLike Xdebug? Consider a donation:http://xdebug.org/donate.phptwitter: @derickr and @xdebug

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#10 Nov. 23, 2010 14:59:35

Derick R.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] [RFC] Release Process


On Tue, 23 Nov 2010, Ferenc Kovacs wrote:

> On Tue, Nov 23, 2010 at 2:59 PM, Derick Rethans <der***@*hp.net> wrote:
>
> > On Tue, 23 Nov 2010, Ferenc Kovacs wrote:
> >
> > > > All the rest you write in the RFC is basically already as we do it.
> > >
> > > yeah, maybe, but they aren't written down, accepted and well-known
> > > rules, so you can forgot/misunderstand/bend them. :/
> >
> > And I don't think that is a bad thing. It's good to be able to be
> > flexible.
> >
> Its good for you, but its bad for the people, who expect you to follow the
> rules, you know, the vendors, developers, etc.

Well, vendors don't follow rules in the first place. They just add
random patches anyway. Developers are pretty much aware what a bug fix,
security bug fix and development tree means. With an annoucement (which
should really be a regular thing, sortof) of a new minor release, isn't
it clear? In case you say no, don't write an RFC that requires really
strict following, but instead write guidelines that match current
practise.

Derick

--http://derickrethans.nl|http://xdebug.orgLike Xdebug? Consider a donation:http://xdebug.org/donate.phptwitter: @derickr and @xdebug

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

  • Root
  • » PHP
  • » [PHP-DEV] [RFC] Release Process [RSS Feed]

Board footer

Moderator control

Enjoy the 12th of December
PoweredBy

The Forums are managed by develissimo stuff members, if you find any issues or misplaced content please help us to fix it. Thank you! Tell us via Contact Options
Leave a Message
Welcome to Develissimo Live Support