After discussing the whole beta/broken deps thing with Doug on irc I found out that 'the thing with JSON' was/is considered a fluke.

Since I obiously stroke a nerve somewhere I will give in and say that:

• I will consider the JSON episode a fluke even though my gut says it won't, the future will tell.
• I do understand how that makes all my arguments irrelevant so I agree on that with JT.
• I still hope that might such a problem occur in the future a shunt will be used to solve it.

 
(10:04:57 PM) preaction: SynQ, i bore the brunt of that dependency problem, and our team came up with all the ways to get around it. i was livid, ready to scream at JT to find another player for this game of "What is the API and when do we say it's broken?"
(10:07:30 PM) SynQ: what does livid mean?
(10:08:22 PM) preaction: it's that kind of angry where your face turns red, you start sweating and smoke starts pouring out your ears
(10:08:40 PM) perlDreamer: topsub: if you nopaste your code I'll poke at it a bit
(10:08:52 PM) preaction: i spent literally days trying to get my dev box back to a workable state
(10:09:05 PM) SynQ: ok
(10:09:36 PM) SynQ: but do you agree that stable should mean you keep your set of dependancies as tight and original as possible?
(10:09:39 PM) SynQ: or don't you?
(10:09:44 PM) SynQ: or something in the middle?
(10:11:12 PM) preaction: the JSON thing was a fluke, but it may be possible to modify testenvironment.pl to handle things like downgrading dependencies or building dependencies in the /data/WebGUI/lib directory
(10:11:34 PM) preaction: perhaps we could handle all our deps that way, but then we're getting... weird...
(10:12:48 PM) perlmonkey2: dang it.....am I really this stupid. I'm trying to get the template to include the uri of the wobject so that ajax calls can be made to it.
(10:12:56 PM) SynQ: what is a fluke
(10:13:01 PM) SynQ: man, you are litterate
(10:13:05 PM) preaction: a rare occurance
(10:13:08 PM) SynQ: ah
(10:13:09 PM) perlDreamer: fluke is a 1-time, rare occurance
(10:13:23 PM) SynQ: I think that the JSON thing will prove not to be a fluke
(10:13:27 PM) preaction: something that skews an otherwise uniform data set
(10:13:45 PM) SynQ: perhaps that is what JT is disagreeing with me on

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

Whould I be correct if I draw this conclusion:

Developing WebGUI is a task that takes a lot of time, especially when it is being done in a professional way. Providing for a predictable development scheme is part of that professionality. So is providing users with a stable version they can run safely and comfortably without having to worry about security problems, feature changes or bugs.

When enough time is taken to develop quality code in a beta branch WebGUI can advance further. When too much time is taken for this process features are not coming to the stable version fast enough and users might choose other systems instead of WebGUI.

A halfyearly release cycle is not enough time to get some to the more desirable stuff done, a yearly release cycle is. Among those are:

• Larger projects like complete overhaul of the commerce system
• Books and documentation available at releasedate of the new stable version

Drawbacks for a yearly cycle as opposed to a halfyearly cycle are:

• It takes longer for features to get into the stable version, which might decrease the Fund a Feature participation.
  
• People who need functionality from the beta track will have problems upgrading to it (can be solved by quarterly shunts).

Steps forward for a yearly cycle as opposed to a halfyearly cycle are:

• There is enough time to get big projects (5 till 10 month taking projects) done.
• A clear development path that can be accounted on will be in place for at least 1 year (or more?).
  

Discussions that are related to the release cycle period but do not have a direct or decisive impact on this, are:

• Changing dependancies and how to deal with that
  
• A way to use beta funcionality in the stable release (backports).
  

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

Sounds like a clear cut case to me which leaves me with one question. A question you will probably not like very much. It is a question of commitment. A question of a man's word. And I am not asking you to put you in the spot or in a corner. I want to find out how certain you feel about this choice now and what we can expect in the future.

If the descision to switch to a year long release cycle is made now, how long will it stay in place? I know that if it doesn't work  well it will have to be changed. When will the choice for this period of time be re-evaluated? March 2009? August 2009?

You'll understand ofcourse that if you do not answer these questions the certainty that is the goal of such a release cycle will deminish a lot. I hope this does not upset you and I hope you will not feel like I'm trying to get you to promise something you cannot keep true, and I am afraid that it will upset you, but I have got to ask.

For the the most part you are correct. You have missed a number of reasons that I want to do a year long release cycle which basically comes down to two things. 
Each time we do a major release is a very time expensive proposition for plain black. 
There likely won't be enough features being added in the fall of the year to warrant a release because I don't work on webgui r&d in the fall and I write the vast majority of the code going into the core. 
JT

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

If the descision to switch to a year long release cycle is made now, how long will it stay in place? I know that if it doesn't work  well it will have to be changed. When will the choice for this period of time be re-evaluated? March 2009? August 2009?

As far as I'm concerned pretty much everything is fluid. Anything is  open to re-evaluation at any time. I'm not infallible like the Pope. =) If someone has an idea that's solves a problem in a significantly  better way than I solved it, then we should move that direction.

As far as this release cycle question goes. If we did a year long  
release cycle, I think it would probably stay that way permanently.  
The only thing I can see changing that (at this point, since I'm not a fortune teller either) is:

Starting July '09 we're going to begin work on WebGUI 8. Something might come up in that process that requires us to delay a release, but I would work hard to make sure that the WG8 dev process went out on schedule, which is currently set for July 2010.

To sum up:

1) JT is not the Pope.
2) JT is not a fortune teller.
3) WebGUI 8 is planned to be a 1 year dev cycle.
4) Someone may come up with a reason after we decide to go to a rigid 12 month release cycle that makes it so we have to go back to a 6 month cycle after we make the move.

After this last try I will give up on getting straight answers from JT.

In between the lines I read this:

1) For now a 1 year or a 1/2 year dev cycle will probably be used.
2) There is no garantee that PlainBlack will not change this at any give time if anyone comes up with a good argument to do that.
3) If you have to plan on anything, you'd better not plan on WebGUI since in all planning and dates around WebGUI pretty much everything is fluid.

What I would like to have read was this:

We will evaluate the one year dev cycle after using it for at least one year, that is probably in June or July 2009.

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

Now this is the JT I like. :)

> 1) For now a 1 year or a 1/2 year dev cycle will probably be used.
>
As of right now we are on a half year schedule. I have proposed a 1  
year schedule. No decision has been made as to whether we will switch  
or not.

Ok, that is straight. Cannot get it much straighter than this.

> 2) There is no garantee that PlainBlack will not change this at any  
> give time if anyone comes up with a good argument to do that.
Correct.

That is very clear too.

> 3) If you have to plan on anything, you'd better not plan on WebGUI  
> since in all planning and dates around WebGUI pretty much everything  
> is fluid.

To put a plan in motion without considering the possibility of change  
is both foolish and dangerous. So yes I keep my mind open for change.  
However, I don't change things willy-nilly. As I stated in my last  
post, someone would have to propose something significantly better  
than how things are done currently in order for me to change. In other  
words the long term benefits must outweigh the benefits of the current  
way of doing things plus the cost (time, effort, opportunity cost, $$
$) of making the change.

Fair enough.

> What I would like to have read was this:
>
> We will evaluate the one year dev cycle after using it for at least  
> one year, that is probably in June or July 2009.

I'm sorry that things are not black and white. This is not a black and  
white world. And to lock Plain Black or WebGUI into some arbitrary  
decision like that is not a smart decision. Would you rather me tell  
you the truth, which I have done, or give you a promise that I may not  
be able to keep like politicians do?

No, I would not like you to give us a promise that you will not be able to keep.

But I would like to show you that if you say 'hey, you know what, let's have a development cycle that is predictable' you actually stick to it so that it is predictable.

In that line it might be better to do as Yung suggested and keep the half year cycle at least another half year to see if it proves itself and then possibly change it to a yearly cycle.

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