Eh? I first learned about XenForo on Milepoint.com, a board now with almost 2M posts that was launched in Nov 2010 when the latest announced release was 1.0.0 Beta 3.
Should developers have early access to Beta releases?
- Thread starter Mike Edge
- Start date
Eh? I first learned about XenForo on Milepoint.com, a board now with almost 2M posts that was launched in Nov 2010 when the latest announced release was 1.0.0 Beta 3.
Let me re-arange that for you a little with some notes... and see how things differ.
1) Development - [SIZE=+0]Not suitable for end user live deployment[/SIZE]
3) Internal alpha test - [SIZE=+0]Not suitable for end user live deployment[/SIZE]
5) Public install at XenForo.com. -[SIZE=+0] [SIZE=+0]Not suitable for end user live deployment[/SIZE][/SIZE]
6) Public availability beta test - [SIZE=+0]Not suitable for end user live deployment [SIZE=+0](everyone gets to test their addons and fix them)[/SIZE][/SIZE]
7) Release - [SIZE=+0]Ready for end user live deployment[/SIZE]
Thats the difference.... at the end of the day no?
Mike Edge
Well-known member
I love this whole idea @Chris Deeming except for that, names shouldn't be from a hat. Really at that stage it's not about fairness but rather hand picking the people with ability to search and find bugs, break things and report them correctly. Choosing from a hat, you can get people who don't even ever install it to test it.
If it's not broke, why fix it?
@Kier @Ashley and @Mike have always preferred to keep everyone in the process -vs- having a closed inner circle. It's what has made XenForo such a success and continues to make it an easy development to follow along with.
Because all customers are treated equally when development and releases are concerned.
I agree, but my concern would be slowing down the releases to the rest of us. If they can draw more people into the internal release & installation testing without slowing it down, I'm fine with that, and add-on developers are a logical group to pull from. I'd also expect such participants to be hand-picked, nothing "fair & impartial" about it.
Surely add-on developers would be primarily interested in updating their own add-ons?
In which case, regular large forum owners running default installs would be a better choice?
Just making a point that a lot of people can't or don't want to grasp...
The only thing I can see having a closed beta doing is causing people to moan and cry about it (just look what happened with the closed RM beta).
I mean, let me ask you straight up. Lets say you got beta access right now, what benefit does that provide, that you can't do in the public beta?
Mike Edge
Well-known member
I never said that. I said those chosen, should be hand picked with knowledge to find and report bugs, not just some random John Doe with a draw from a hat.
Jeremy
in memoriam 1991-2020
Although I agree with this statement, I think a combination of the two would be 'ideal' in that situation. No offense to anyone, but in my work I've always found bug reports coming from other developers to be more helpful than non-developers most of the time (this is happening as I write this with some bug reports I'm receiving). Not to say that normal users can't report good reports, because I've received some fantastic reports that way.
Mike Edge
Well-known member
I think the moaning was more over some using the closed RM beta on production sites then being picked or not. IMO doing a closed beta like that should simply have a NDA.
If I got beta 1.2 right now it would provide absolutely zero benefit as public availability probably isn't more than a week away.
If a group of testers got hold of it before it was installed here, however, that would have meant a lot less bugs being discovered in public and potentially it getting the polish it has now (that it didn't on the 3rd of June) in private testing which would ultimately have made the public install and testing and release all the more a quality product.
If a group of testers got hold of it before it was installed here, however, that would have meant a lot less bugs being discovered in public and potentially it getting the polish it has now (that it didn't on the 3rd of June) in private testing which would ultimately have made the public install and testing and release all the more a quality product.
Doesn't match the reality of most environments I've worked in. We used to run a production timesharing system on a pair of CDC mainframes (4 CPUs total) 6 a.m to 10 p.m. At 10 p.m. we kicked everyone off, reloaded with OUR software, and ran alpha/beta/really wobbly until 6 a.m. with the same users & file system. It was an extremely productive environment. If we screwed up too badly, well, that's why we had ops & backups.
For reasons of legal liability, I don't see XF pushing betas as a production platform. At the same time, if you want to the most out of the beta cycles, that is exactly what needs to happen: Real testing requires real users who find real issues by creating real-life situations with real software running on real systems. Note the word "real" -- it matters.
jmurrayhead
Well-known member
vB can have all the open testing in the world and it wouldn't make a difference because it stops at management. This is very different. This is also more about allowing addon developers to catch up their addons before the majority of users upgrade.
Hornstar
Well-known member
The majority of users won't upgrade during a beta.
jmurrayhead
Well-known member
And you think there will have been enough time for addons to be updated by the time 1.2 is released as stable? Regardless, I don't understand the objection to some developers getting early access. Makes no sense and hurts no one.
Wildcat Media
Well-known member
Exactly. The beta/RC cycle should be long enough that developers can tweak their products to work on 1.2. And especially in the RC stage, I'm pretty sure 1.2 will be "feature frozen" and it will be down to only minor bug fixes.
Having said that, I'd take 1.2 yesterday if it were released...and I'm not even a developer.
