Way back in June 2002.....

[Chris Stewart]

I am talking about one thing, releasing the style with the Release Candidate.

I agree it has taken too long, and the preview site should not have been opened until we were ready to enter into a Beta Status. I also think some features such as RSS Feeds, Subscriptions, Cron Jobs and other "external" features should have been rolled out in a 2.5 version which would have gotten them into the hands of the customers and used in the thousands of server setups which we cannot test on.
However, what is done is done and lamenting on the past isn't going to help anyone.

I agree on all accounts. However, people are still going to complain about the past until it is clear there is a new direction as far as project planning and an official statement is made laying it out.

[InSite]

Semantics... You aren't working for the company so you do not know what the development process is like here.

I'd disagree. As customers, we are perfectly placed to judge the effectiveness and success of your development processes.

[Wayne Luke]

I am talking about one thing, releasing the style with the Release Candidate.

I agree it has taken too long, and the preview site should not have been opened until we were ready to enter into a Beta Status. I also think some features such as RSS Feeds, Subscriptions, Cron Jobs and other "external" features should have been rolled out in a 2.5 version which would have gotten them into the hands of the customers and used in the thousands of server setups which we cannot test on.
However, what is done is done and lamenting on the past isn't going to help anyone.

[Chris Stewart]

I understand that, but it obviously has not been the best for vB3. Scott even said this has taken too long himself.

[Wayne Luke]

Semantics... You aren't working for the company so you do not know what the development process is like here. Each company has different methods and implementation standards.

When we release a new major version, we change the style of vBulletin and rewrite the interface of the website. This is done as close to release as possible. It is a business choice on our part.

[Chris Stewart]

An operating system is a tad different than forum software.

Btw, Windows is built every night. There is an interesting article about it here (http://www.winsupersite.com/reviews/...r2k3_gold1.asp , there are three parts). I wouldn't equate a build to a beta either. If you think about it that way, vB3 would be on beta ~500 something (1.5 years in development maybe?).

[Wayne Luke]

7 betas reflect negatively on the product IMO. I think many would agree with me. I mean look at some of the stuff going on in the bug tracker (http://www.vbulletin.com/forum/bugs....view&bugid=880). The subscription system is getting a re-write after beta 7. Sounds like something that should have been solid before released to the public. Not to mention all of the trouble that can come from a complete re-write of the style. You think 500 bugs is a lot in 4 betas? I can't imagine how many more could come of a new style system. Nothing against Kier, but it's tough to get something that large perfect the first time (i.e., vB3 ).

Windows XP went through 2000 beta compilations... In fact, the version people are using is the 2600 compilation of the product.

The style system is in place in Beta 7. The Language system is in place in Beta 7. The new style will be tying those things together and changing some HTML. Nothing which will change the operation of vBulletin.

[Chris Stewart]

iDavid, you are certainly correct. But, there should never be a critical rewrite in the RC stage. Obviously never planned but also not by finding an issue. Any issue that would cause a complete rewrite of a critical part of the system should be found before the application reaches RC.

[iDavid]

There are "standards" in release management, such as
1) alphas = new major code introduced or rewritten
2) betas = minor new features / rewrites
3) RC = critical rewrites and minor fixes

Thank you; I think that's very accurate!

I will note, however (and I think you agree, but this is just to clarify), that "critical rewrites" in the RC stage should not, ideally, happen -- they're solely when a last-minute code base is found not to work correctly in production, not routine, planned rewrites of code that has known problems.

And, interestingly, looking at those definitions, it seems that we're almost entering the beta stages.

Oh, and squall -- one should never assume multiple RCs or leave bugs for "RC2". The first RC should, ideally, always be released as final (though, in practice, that's rarely the case).

[Chris Stewart]

I've worked on major software releases, and also handled release management for projects more complex than vBulletin.
There are "standards" in release management, such as
1) alphas = new major code introduced or rewritten
2) betas = minor new features / rewrites
3) RC = critical rewrites and minor fixes

I'm not sure about you, but I'd call the new style a major change. Definitely not "critical rewrite" or "minor fix".
Yes, jelsoft have a lot of work to do when it comes to release management in the future..

Someone who has a clue, thank you.

[rylin]

I've been on teams for projects a little smaller than this, but some have held a much larger impact (read: $$$). What most people don't seem to get is that these guys don't even appear to be going by any sort of plan. Looks very unorganized. I understand this isn't the only job for some of these guys (as far as I know), but this is a selling product with many people waiting. The execution should have been better and some of the devs have already acknowledged that.

[rylin]

Who says it has to be done this way. There are no guidelines Jelsoft needs to abide by when releasing vB. You're asumptions of correct software production are different from mine as is mine are different from the next persons. I would venture to guess that you have not released anything on the scale of vBulletin, so you probably don't have near the clue the vB team does when it comes to betas, alphas, RCs. Let them carry it out how they planned, because changing their plans now is only going to hault the process even more. So until you can be an asset to the release and start helping rather than *****ing, close the yapper, sit down and wait like the rest of us.

kthx

I've worked on major software releases, and also handled release management for projects more complex than vBulletin.
There are "standards" in release management, such as
1) alphas = new major code introduced or rewritten
2) betas = minor new features / rewrites
3) RC = critical rewrites and minor fixes

I'm not sure about you, but I'd call the new style a major change. Definitely not "critical rewrite" or "minor fix".
Yes, jelsoft have a lot of work to do when it comes to release management in the future..

[DarkDelight.net]

The REAL question is, where are John and James!

The real question is, WHO are John and James?

I'll bet they're both Kier and he's pocketing three pay cheques.

[N9ne]

The REAL question is, where are John and James!

[Chris Stewart]

I've been on teams for projects a little smaller than this, but some have held a much larger impact (read: $$$). What most people don't seem to get is that these guys don't even appear to be going by any sort of plan. Looks very unorganized. I understand this isn't the only job for some of these guys (as far as I know), but this is a selling product with many people waiting. The execution should have been better and some of the devs have already acknowledged that.