Plain Black, makers of WebGUI - Re: 7.6 and beyond

JT

Date: 3/29/2008 5:50 pm · Subject: 7.6 and beyond · Rating: 0

I have to say that I really liked having the better part of a year to
work on WebGUI 7.5. Plus it allowed us to make WebGUI 7.4 an amazingly
stable version that people could depend on. Given that, I think that
WebGUI 7.6 and beyond should each also be year long development
efforts. So it would work like this:

7.5 feature freeze will go into effect May 31.
7.5 will be bug fixed and tested thoroughly through June.
7.5 will become the new stable in July.
7.4 is provided a direct upgrade path to 7.5 in July.
7.6 becomes the new beta.

-- above this line was always the plan, ever since i announced it at
the WUC last year, below here is where it changes ---

Instead of doing it all over again in December / January where we move
from 7.6 to 7.7 I think we should wait until June/July again. So the
next upgrade path will again be:

7.6 feature freeze will go into effect May 31, 2009.
7.6 will be bug fixed and tested thoroughly through June, 2009.
7.6 will become the new stable in July, 2009.
7.5 is provided a direct upgrade path to 7.6 in July, 2009.
7.7 becomes the new beta.

This gives those wanting the very stable version of WebGUI a year of
bug fixes. And it gives the WebGUI development crew a year to lay in
some really nice features for the next release, rather than rushing
just to get something done.

I'm already leaning strongly this direction, but I'd like to hear your
arguments for and against before I make my decision final.

JT Smith
ph: 703-286-2525 x810
fx: 312-264-5382

Create like a god. Command like a king. Work like a slave.

Back to Top

Rate [ | ]

arjan

Date: 3/29/2008 7:45 pm · Subject: Re: 7.6 and beyond · Rating: 1

Hi JT,

I like that a lot.

Kind regards,
Arjan.

On Sat, 2008-03-29 at 17:50 -0500, jt@plainblack.com wrote:
> JT wrote:
>
> I have to say that I really liked having the better part of a year to
>
> work on WebGUI 7.5. Plus it allowed us to make WebGUI 7.4 an
> amazingly
> stable version that people could depend on. Given that, I think that
> WebGUI 7.6 and beyond should each also be year long development
> efforts. So it would work like this:
>
> 7.5 feature freeze will go into effect May 31.
> 7.5 will be bug fixed and tested thoroughly through June.
> 7.5 will become the new stable in July.
> 7.4 is provided a direct upgrade path to 7.5 in July.
> 7.6 becomes the new beta.
>
> -- above this line was always the plan, ever since i announced it at
> the WUC last year, below here is where it changes ---
>
> Instead of doing it all over again in December / January where we
> move
> from 7.6 to 7.7 I think we should wait until June/July again. So the
> next upgrade path will again be:
>
> 7.6 feature freeze will go into effect May 31, 2009.
> 7.6 will be bug fixed and tested thoroughly through June, 2009.
> 7.6 will become the new stable in July, 2009.
> 7.5 is provided a direct upgrade path to 7.6 in July, 2009.
> 7.7 becomes the new beta.
>
> This gives those wanting the very stable version of WebGUI a year of
> bug fixes. And it gives the WebGUI development crew a year to lay in
> some really nice features for the next release, rather than rushing
> just to get something done.
>
> I'm already leaning strongly this direction, but I'd like to hear
> your
> arguments for and against before I make my decision final.
>
>
> JT Smith
> ph: 703-286-2525 x810
> fx: 312-264-5382
>
> Create like a god. Command like a king. Work like a slave.
>
>
>
> http://www.plainblack.com/webgui/dev/discuss/7_6-and-beyond
>

Back to Top

Rate [ | ]

colink

Date: 3/29/2008 9:35 pm · Subject: Re: 7.6 and beyond · Rating: 2

On Saturday 29 March 2008, jt@plainblack.com wrote:

> I'm already leaning strongly this direction, but I'd like to hear
> your arguments for and against before I make my decision final.

$rizen++

This will slow down the release of new features into the stable
branch, but a less buggy WebGUI is a good goal, and people are always
free to go to the beta when they want.

Also, as we found out in doing C2, there's tons of other core code
changes that would be nice to do if we had the time (like implementing
mixins).

Colin

Back to Top

Rate [ | ]

koen

Date: 3/30/2008 6:26 am · Subject: Re: 7.6 and beyond · Rating: 0

I am all for a yearly cycle.

There is something else I would really like, and that is a freeze on the dependancies needed, or at least a pre-defined action in case a dependancy must change.

I'll illustrate this with an example. When going from WebGUI 7.4.21 to 7.4.22 a different version of JSON and JSON::Config was used that broke WebGUI which sort of defeats the whole stable/beta diference. An upgrade of a stable version should, in my opinion allways be a run and go upgrade. And if not, big flashing signs should point out that this isn't a 'patch release'.

I don't know if the new version of JSON was really needed, but that is not the point here. I think we need a procedure in place that accounts for changing dependancies and keeps in mind the whole idea of a stable version.

I can think of numerous reasons to start using a new version of a dependancy, but for a stable release only a security fix or a bug fix should lead to requiry of such a new version.

Perhaps the need to upgrade to a new version of JSON would have been reason enough to say 'hey this is such a big change in the way WebGUI works, this calls for a new release of WebGUI'.

Perhaps the need to upgrade was not really big enough to require it to be used for the stable version of WebGUI.

Perhaps we need a stable and a beta version of the WRE.

Koen de Jonge - ProcoliX
http://www.procolix.com
Hosting - WebGUI - Virtualization

Back to Top

Rate [ | ]

JT

Date: 3/30/2008 10:00 am · Subject: Re: 7.6 and beyond · Rating: 3

This wasn't our choice. If it were up to me json wouldn't have changed, but the owner of that dependency changed it and then we started getting hundreds of people complaining that webgui was broken. So we were forced into the change.

JT
On Mar 30, 2008, at 6:26 AM, <koen@procolix.com> wrote:

koen wrote:

I am all for a yearly cycle.

There is something else I would really like, and that is a freeze on the dependancies needed, or at least a pre-defined action in case a dependancy must change.
I'll illustrate this with an example. When going from WebGUI 7.4.21 to 7.4.22 a different version of JSON and JSON::Config was used that broke WebGUI which sort of defeats the whole stable/beta diference. An upgrade of a stable version should, in my opinion allways be a run and go upgrade. And if not, big flashing signs should point out that this isn't a 'patch release'.
I don't know if the new version of JSON was really needed, but that is not the point here. I think we need a procedure in place that accounts for changing dependancies and keeps in mind the whole idea of a stable version.
I can think of numerous reasons to start using a new version of a dependancy, but for a stable release only a security fix or a bug fix should lead to requiry of such a new version.
Perhaps the need to upgrade to a new version of JSON would have been reason enough to say 'hey this is such a big change in the way WebGUI works, this calls for a new release of WebGUI'.
Perhaps the need to upgrade was not really big enough to require it to be used for the stable version of WebGUI.
Perhaps we need a stable and a beta version of the WRE.
Koen de Jonge - ProcoliX
http://www.procolix.com
Hosting - WebGUI - Virtualization

http://www.plainblack.com/webgui/dev/discuss/7_6-and-beyond/3

--

Plain Black, makers of WebGUI
http://plainblack.com

Back to Top

Rate [ | ]

koen

Date: 3/30/2008 4:16 pm · Subject: Re: 7.6 and beyond · Rating: 0

I know and understand that it wasn't the choice of PlainBlack or any of the WebGUI programmers. I am not blaming anyone for what happened and I also think that in the current scheme it is unavoidable.

But JSON is only an example of what happens when a dependancy changes it's not the point that I am trying to make.

I think we need: a freeze on the dependancies needed, or at least a pre-defined action in case a dependancy must change.

Do you agree on that?

This wasn't our choice. If it were up to me json wouldn't have changed, but the owner of that dependency changed it and then we started getting hundreds of people complaining that webgui was broken. So we were forced into the change.

JT

Koen de Jonge - ProcoliX
http://www.procolix.com
Hosting - WebGUI - Virtualization

Back to Top

Rate [ | ]

JT

Date: 3/30/2008 7:00 pm · Subject: Re: 7.6 and beyond · Rating: 0

No absolutely not. As I said I already didnt want to upgrade JSON in this case but had no choice. So you are trying to back me into a corner here getting me to say that I'll lock prereqs, and then another situation like this past one will come up and it will make me look like I broke a promise. When in reality it is entirely out of my control.
It has always been and will always be my goal not to change prereqs within a release. I can promise nothing more than that.

JT
On Mar 30, 2008, at 4:16 PM, <koen@procolix.com> wrote:

koen wrote:

I know and understand that it wasn't the choice of PlainBlack or any of the WebGUI programmers. I am not blaming anyone for what happened and I also think that in the current scheme it is unavoidable.
But JSON is only an example of what happens when a dependancy changes it's not the point that I am trying to make.
I think we need: a freeze on the dependancies needed, or at least a pre-defined action in case a dependancy must change.
Do you agree on that?

This wasn't our choice. If it were up to me json wouldn't have changed, but the owner of that dependency changed it and then we started getting hundreds of people complaining that webgui was broken. So we were forced into the change.

JT

Koen de Jonge - ProcoliX
http://www.procolix.com
Hosting - WebGUI - Virtualization

http://www.plainblack.com/webgui/dev/discuss/7_6-and-beyond/7

--

Plain Black, makers of WebGUI
http://plainblack.com

Back to Top

Rate [ | ]

koen

Date: 3/31/2008 12:47 am · Subject: Re: 7.6 and beyond · Rating: 1

I am not trying to 'back you into a corner', on the contrary. I'm trying to prevent anyone from saying: 'hey it was your fault that the prereqs changed'.

I'll rephrase what I'm trying to say:

When the prereqs of a stable version change in such a way that they heavily affect the 'easy upgrade' of that stable WebGUI version there should be a procedure in place that will deal with that.

No absolutely not. As I said I already didnt want to upgrade JSON in this case but had no choice. So you are trying to back me into a corner here getting me to say that I'll lock prereqs, and then another situation like this past one will come up and it will make me look like I broke a promise. When in reality it is entirely out of my control.
It has always been and will always be my goal not to change prereqs within a release. I can promise nothing more than that.

JT
On Mar 30, 2008, at 4:16 PM, <koen@procolix.com> wrote:

koen wrote:

I know and understand that it wasn't the choice of PlainBlack or any of the WebGUI programmers. I am not blaming anyone for what happened and I also think that in the current scheme it is unavoidable.
But JSON is only an example of what happens when a dependancy changes it's not the point that I am trying to make.
I think we need: a freeze on the dependancies needed, or at least a pre-defined action in case a dependancy must change.
Do you agree on that?

Koen de Jonge - ProcoliX
http://www.procolix.com
Hosting - WebGUI - Virtualization

Back to Top

Rate [ | ]

JT

Date: 3/31/2008 7:51 am · Subject: Re: 7.6 and beyond · Rating: 0

And what magic bullet would you prescribe that would work universally. I'm a fan of "do the best you can". It works everywhere.

JT
On Mar 31, 2008, at 12:47 AM, <koen@procolix.com> wrote:

koen wrote:

I am not trying to 'back you into a corner', on the contrary. I'm trying to prevent anyone from saying: 'hey it was your fault that the prereqs changed'.
I'll rephrase what I'm trying to say:
When the prereqs of a stable version change in such a way that they heavily affect the 'easy upgrade' of that stable WebGUI version there should be a procedure in place that will deal with that.

No absolutely not. As I said I already didnt want to upgrade JSON in this case but had no choice. So you are trying to back me into a corner here getting me to say that I'll lock prereqs, and then another situation like this past one will come up and it will make me look like I broke a promise. When in reality it is entirely out of my control.
It has always been and will always be my goal not to change prereqs within a release. I can promise nothing more than that.

JT
On Mar 30, 2008, at 4:16 PM, <koen@procolix.com> wrote:

koen wrote:

I know and understand that it wasn't the choice of PlainBlack or any of the WebGUI programmers. I am not blaming anyone for what happened and I also think that in the current scheme it is unavoidable.
But JSON is only an example of what happens when a dependancy changes it's not the point that I am trying to make.
I think we need: a freeze on the dependancies needed, or at least a pre-defined action in case a dependancy must change.
Do you agree on that?

Koen de Jonge - ProcoliX
http://www.procolix.com
Hosting - WebGUI - Virtualization

http://www.plainblack.com/webgui/dev/discuss/7_6-and-beyond/9

--

Plain Black, makers of WebGUI
http://plainblack.com

Back to Top

Rate [ | ]

koen

Date: 3/31/2008 8:04 am · Subject: Re: 7.6 and beyond · Rating: 3

I would suggest that if such an intrusive upgrade (api-break) of one of the dependancies would occur that the pre-defined action is to NOT use the newer version of that dependancy.

Instead keep on using the older version of that dependancy until the beta becomes stable and merge it then.

And what magic bullet would you prescribe that would work universally. I'm a fan of "do the best you can". It works everywhere.

JT
On Mar 31, 2008, at 12:47 AM, <koen@procolix.com> wrote:

koen wrote:

I am not trying to 'back you into a corner', on the contrary. I'm trying to prevent anyone from saying: 'hey it was your fault that the prereqs changed'.
I'll rephrase what I'm trying to say:
When the prereqs of a stable version change in such a way that they heavily affect the 'easy upgrade' of that stable WebGUI version there should be a procedure in place that will deal with that.

No absolutely not. As I said I already didnt want to upgrade JSON in this case but had no choice. So you are trying to back me into a corner here getting me to say that I'll lock prereqs, and then another situation like this past one will come up and it will make me look like I broke a promise. When in reality it is entirely out of my control.
It has always been and will always be my goal not to change prereqs within a release. I can promise nothing more than that.

JT
On Mar 30, 2008, at 4:16 PM, <koen@procolix.com> wrote:

koen wrote:

I know and understand that it wasn't the choice of PlainBlack or any of the WebGUI programmers. I am not blaming anyone for what happened and I also think that in the current scheme it is unavoidable.
But JSON is only an example of what happens when a dependancy changes it's not the point that I am trying to make.
I think we need: a freeze on the dependancies needed, or at least a pre-defined action in case a dependancy must change.
Do you agree on that?

Koen de Jonge - ProcoliX
http://www.procolix.com
Hosting - WebGUI - Virtualization

Back to Top

Rate [ | ]