Proposal - UBB.Developers

UBB.Dev

I propose the following:

1) All UBB code hackers should develop alpha versions for a group of hand-picked, private testers to work out initial bugs. No alpha's are to be posted here.

2) Once alphas are deemed stable enough for wide release, then the code hacker may post a version for beta download here, including limited support and updates as may be necessary.

And...
* All betas posted here are considered wide betas
* All betas posted here must be auto-installable, i.e. Troy's excellent product, MultiHack.

3) Once beta is cleaned up and stable, it's released as public non-beta.

And...
* The beta thread should be DELETED
* Add finished product to database here

4) Any final (non-beta) hack should be written ONLY for the latest final (non-beta) UBB release by Infopop.

5) Any Infopop UBB beta does not have to be supported by the UBB code hacker, but if they opt to do so... it must be a SEPARATE release, in wide beta form.

6) By no means will any UBB code hacker be allowed to post "tests" which only anger and patronize users, no matter the good intent. This is why #1 posted above exists, and is the proper way to test and release software.

Thoughts and comments appreciated. Please move this to another area if this was posted off-topic.

Sounds like a really nice plan to me, you have good ideas.

quote:

1) All UBB code hackers should develop alpha versions for a group of hand-picked, private testers to work out initial bugs. No alpha's are to be posted here.

i think most already do that, in so much as doing the testing themselves or with a few others. i know i certainly do.

quote:
All betas posted here must be auto-installable, i.e. Troy's excellent product, MultiHack.

no offense to troy, but you will never get autoinstalls from me. if your gonna mess with your code you should at least take a hands on approach so you have more familiarity when things screw up.

quote:
4) Any final (non-beta) hack should be written ONLY for the latest final (non-beta) UBB release by Infopop.

there are still a lot of 5.xx users, to say nothing of the people that will choose to stay with 6.0x, why should they no longer have hack options. i dont believe its fair to force people to upgrade.

quote:
6) By no means will any UBB code hacker be allowed to post "tests" which only anger and patronize users, no matter the good intent. This is why #1 posted above exists, and is the proper way to test and release software.

i have an idea, how bout we no longer posts betas cause they may anger users, oh and while we are at it why dont we no longer post any hacks, cause still more users are only frustrated and angered when they dont do what they want the hacks to do...

i dont mean to come off sounding angry here, but maybe you dont understand that all these hacks are written for free, in peoples spare time. it is NOT our job to supply you with all the hacks you want/need for your boards.
im glad you have an idea of the "proper" testing methods (as they fit into the waterfall method at least, and we all just love that one im sure), but these are small code modifications that benefit from the added stress testing of being in public "beta", and really i dont see how any of your "rules" are actually usefull in making better hacks.

quote:
Originally posted by AccessDenied:
1) All UBB code hackers should develop alpha versions for a group of hand-picked, private testers to work out initial bugs. No alpha's are to be posted here.

I believe a warning is enough.

quote:
2) Once alphas are deemed stable enough for wide release, then the code hacker may post a version for beta download here, including limited support and updates as may be necessary.

And how is it now?

quote:
* All betas posted here must be auto-installable, i.e. Troy's excellent product, MultiHack.

I agree that all hacks should be auto-installable, I agree that MultiHack is a GREAT program, but some owners don't have enough time to do it.

quote:
3) Once beta is cleaned up and stable, it's released as public non-beta.

And...
* The beta thread should be DELETED
* Add finished product to database here

True, I agree that the database should have any finished mod's download link, and a discussion thread in the finished mods forum.

quote:
4) Any final (non-beta) hack should be written ONLY for the latest final (non-beta) UBB release by Infopop.

Like Jordo said, it's unfair. Even some authors' members area access expired, so they can't post finished mods?

quote:
6) By no means will any UBB code hacker be allowed to post "tests" which only anger and patronize users, no matter the good intent. This is why #1 posted above exists, and is the proper way to test and release software.

I have to agree with Jordo here as well.

quote:
Originally posted by jordo:

there are still a lot of 5.xx users, to say nothing of the people that will choose to stay with 6.0x, why should they no longer have hack options. i dont believe its fair to force people to upgrade.

OMG, the new and improved Kakaugaul!!!

Actually, the ubbdev staff banned you on purpose, not by mistake.

Any Jim, you have some good ideas, but for the most part I agree with jordo and LK. We do this for free, in our spare time, for fun.

I tend to agree with both sides on this. I don't see why a happy medium couldn't be worked out.

Jordo, no offense taken. =) However I don't understand your logic for your decision(although I respect it).

I mean, that is like saying that if you don't know how the HTTP protocol works you shouldn't look at web pages.

There are a LOT of people that use these hacks that have NO IDEA how they work(myself included, although I can poke around enough to understand the code, if not actually code it).

I'm not saying you should use MultiHack specifically, but I think not doing some sort of auto install does leave the non-techincal and the people that just want a product not the stones used to build it.

Either way though, if your hack is popular enough, people will ask for a MultiHack version. I get a lot of requests for me to make MultiHack formatted hacks. I just don't have the time to do it or I would make more.

[EDIT]
Ohh, for those of you that do use MultiHack there is a new bugfix release. Fixes several small problems as well as the "Overwrite Source Files" now works correctly when installing a hack.

[ August 14, 2001: Message edited by: Troy ]

quote:
Originally posted by AccessDenied:

* All betas posted here must be auto-installable, i.e. Troy's excellent product, MultiHack.

Alot of people don't seem to like to use auto-installers, as well as people can learn alot more from installing it manually than using an auto installer.

If you're too lazy to manually insert code, you shouldn't be adding modifications in the first place.

Don't get me wrong, if the developer wants to create an auto installer as well, that's fine, I, as well as others, do not like using auto installers.

This is pretty much what LK and Jordo said.

I don't think jordo has a problem with people making mhk's of his work, he just doesn't support them

The only problem I have with auto-installer files is that they get out-dated real quick every time a new bug is fixed in the modification's files, other than that, I like them quite a bit. They do cut down on support questions (provided the mhk was put together correctly) and save a good bit of time on multiple installs. Multihack is the best of these auto-installers so far by far.

As for an "official" development cycle, I agree that uniformity in the development cycle would help in most areas, rigid required structures is asking a little much for those who donate their time in this tho. We try to help where we can by promoting the "finishing" of modifications. Old beta threads are closed with pointers to the finished thread, then after some time has passed, are "reaped" to our boneyard forum to keep confusion down among the newer members. Finished modifications are added to the db when appropriate. Not all "hacks" that go in the finished forum make it into the db tho, as some are of the "align="center"" variety and really aren't quite what could be considered finished modifications.

One thing that needs to be considered here is that most people are used to the amount of development time that went into the 5 series modifications... some have been around well over a year. Not true with v6... the development cycle really didn't last long wth 6.0.x until it started with 6.1.x, which is nearly a complete re-write in a good number of aspects... it will probably be this fall before the base code is stable enough that development can proceed without it being such a moving target. Development should begin to sort itself out once 6.1.0 is released... 6.2.0 most likely won't be such a large change from 6.1.0 as 6.1.0 was from 6.0.x.

A proposed "manageable" development cycle taking into consideration personal time constraints and UBB development cycles:

Alpha/ Beta Development:

drawing board

Not bad Allen.

I think one of the major problems with hacks these days is that they are NEVER out of beta...

We all love new features, etc, but there comes a time when you stop adding new features, clean up what ya have and call it "gold"... Then release a bugfix a week later. heh

Finished Status:
Nothing should be 'hardcoded', so everything that should be changed has to be from the CP, not the source files.

I think I understand what you mean LK, upgrades to fix bugs and add features would be merely file uploads with maybe some configuration in the control panel - that sounds pretty good.

Troy, I agree that it seems like they are never out of beta, that's mainly because of the development cycle of the ubb itself - something that should settle down once we're into 6.1 - 6.2

What really be cool if there was a CVS system for hacks like the one that exists internally for the vBulletin development team.

qasic

has been for a while now...

cal put it together a while back but has put the project on the back-burner until he gets more time to finish it.

AccessDenied: Although I think your intentions are well, I have to agree with Jordo and LK.

I do my ubbmods for pure enjoyment and fun in my spare time. I often dont have the time to make auto-installer files for them and usually only do once the mod becomes so huge its just a pain in the derriere to do them manually.