I don't think a 6 month cycle would really mean that all development would be rushed. There could still be 4 weeks between the feature freeze and the stable release. And a new feature could still be added to the beta a few months before the feature freeze.

That is true. But a true stable user also wouldn't want to rush some new feature into a release to call it stable either. Because it wouldn't be stable enough. I think this is a pretty good compromise, but I will continue to ponder the situation.

On Apr 1, 2008, at 5:02 AM, <yung@unitedknowledge.nl> wrote:

yhkhoe wrote:

Those of you who have concerns about going to a year long dev cycle, please let me know if shunts would resolve most/all of your issues. 

Shunts would not change the fact that a 'true' stable user will have to wait more than 6 months if they pay for an RFE in the beginning of the yearly cycle. 

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

--

Plain Black&#44; makers of WebGUI
http://plainblack.com

JT Smithph: 703-286-2525 x810fx: 312-264-5382
Create like a god. Command like a king. Work like a slave.

I would expect more rush to get a feature in before the feature freeze if there's only one stable release a year instead of two.

Why would the fact that a dev project takes a couple of months mean that it would get rushed. Even with a 6 month cycle there's no need to fit every dev project in one cycle. If there had been a feature freeze and stable release in december/january that wouldn't necessarily have had any effect on Thingy development for example. I could have started before december and finished in march just like i did now.

The new features that i expect people will want to pay for aren't complete assets or things like a commerce overhaul. What i would expect are enhancements of existing applications. Especially recently added ones, like Thingy. After the coming stable release and the wuc a lot of 'stable' users will start using Thingy and the other new apps. They will soon start coming up with extra features and enhancements. Many of these RFE's will only take a few hours or days to built. But it won't be attractive for them to pay to get those built in october if they have to wait until july 2009 to get them in a stable release. In some cases they might wait and have their RFE built later. But there will also be cases where that's not an option because they need it sooner than that.

You might not see any low hanging fruit right now, but if we keep watering the tree some fruit wil grow back every year.

Yung 

I'm not saying development would be rushed for a given feature. But  
I'm saying development overall would be rushed, especially if this  
were in the last half of the year, due to the time constraints I spoke  
about earlier. There is no low hanging fruit in WebGUI anymore. The  
applications we're developing for the core these days take months of  
planning and development. Commerce 2.0 is a 9 month effort. And  
Thingy, which you are quite familiar with, was one month of planning  
and five months of development. Gallery was 4 months, and Calendar was  
3 months. Granted I'm talking "real time" vs "developer time", but the  
release cycle works on real time.

As usual you make good points. However they're all in support of just one point: fund a feature rfes. So I guess what it comes down to is whether your one big point outweighs the bunch of little points I made. I'm just not sure yet. Anybody else have input?

If I am still allowed to participate in this discussion...

I think that for small enhancements a yearly cycle is way too long. Why would we have to put a delay in there that is so long, it's only a small change.

For projects like that redo a complete part of WebGUI a year might be too short. You'll have to be able to finish the code before the feature freeze comes.

What is important about the cycle is that once set it should not be deviated from, since then you know what you can expect and that is the goal.

I won't use examples since they seem to steer the discussion away from the point.

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

As someone whose organization has funded a feature recently and will be funding more in the future, I can say that it is a pain keeping these patched in to the stable release with each update.

I think it would be totally tolerable for yearly dev cycles, however, if the WRE contained some infrastructure to support folks like me.

Here's what I'm thinking:

Have a patches.d directory somewhere in the WRE. Make the webguiupdate.pl script run through that directory and apply the patches to the new code each time it's run. Have it report failures to apply the patches to the local admin and someone at Plain Black (if they built the feature).

Let us put local patches in there, as well as putting funded RFE patches in there. Really, you could probably do this in WebGUI itself (so it worked with or without the WRE).

You could even get fancy and put some scripts in there to submit local patches up to Plain Black for possible inclusion into core.

You could also have the upgrade script check for modified source files (maybe store hashes for them somewhere?) and offer to turn local modifications into local patches, put the new code in place, apply the patches, report failed hunks, etc. etc. Though that's getting *really* fancy. :) (And it would probably require the WRE since the first upgrade step w/o the WRE is to untar the new version over top of the existing one. Though I guess you could change that.)

As usual you make good points. However they're all in support of just one point: fund a feature rfes. So I guess what it comes down to is whether your one big point outweighs the bunch of little points I made. I'm just not sure yet. Anybody else have input?

JT

> Have a patches.d directory somewhere in the WRE. Make the  
> webguiupdate.pl script run through that directory and apply the  
> patches to the new code each time it's run. Have it report failures  
> to apply the patches to the local admin and someone at Plain Black  
> (if they built the feature).
>
> Let us put local patches in there, as well as putting funded RFE  
> patches in there. Really, you could probably do this in WebGUI  
> itself (so it worked with or without the WRE).
>
> You could even get fancy and put some scripts in there to submit  
> local patches up to Plain Black for possible inclusion into core.
>
> You could also have the upgrade script check for modified source  
> files (maybe store hashes for them somewhere?) and offer to turn  
> local modifications into local patches, put the new code in place,  
> apply the patches, report failed hunks, etc. etc. Though that's  
> getting *really* fancy. :) (And it would probably require the WRE  
> since the first upgrade step w/o the WRE is to untar the new version  
> over top of the existing one. Though I guess you could change that.)
>

You're hijacking my thread like Koen did. I'm not a fan of that.

However, I will say that everything you're proposing here is stuff  
that we are accounting for in the new LIFT upgrade system that we're  
designing. We wanted it to go into 7.5, but that's not going to happen  
now, so it will be 7.6 or later instead.



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

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

Uh... OK. Sorry I "hijacked" your thread. It was unintentional. I thought I had some relevant input on the topic at hand, namely release frequency and how paid-for RFE's are impacted by that.

Glad to hear it's being worked on, though.