Why not release a BETA version before the finalized release?

[punkmaister]

Look I have no problem with the developers of this ongoing open source project to get people to try out new compiled versions to see what bugs might be present or not but it would be far, far better to release a BETA version of the upcoming version so those that may want to try it out and help work out the bugs can do so. But when you allegedly launch a finalized product so that all the faithful users end up with a bomb in their faces and have everybody move to the Debug builds is not a good policy at all. My 2 cents...

[ailurophobe]

My bad. I posted something in another thread that punkmaister read too much into. Sorry for the inconvenience. Please ignore the specifics of what he says and just take it as a general complaint of the quality of 2.5.

[punkmaister]

I honestly do not see why releasing a BETA version before the finalized product would not be a good idea.

[old_death]

[ocexyz]

You are wrong Punkmeister. True is that 2.5.0.0 was launched when all reported bugs, and so called blocking tickets in bugtrack, have been fixed and devs were believing that it is clear. So it was launched in good faith I suppose. So, if more ppl would use debug builds then perhaps 2.5.0.0 would not be launched earlier but later.
NOTE that currently we have the same situation: nearest next official release is oncomming and still many ppl having problems do not want to try debug build so they don't want to use beta, so new bugs can remain undiscovered, so devs may not know them - don't have bugreports, SO WILL NOT FIX THEM = THEY WILL REMAIN IN NEAREST OFFICIAL RELEASE if they will remain undiscovered.
Debug builds are just beta versions and are aviable ALL THE TIME, everyday one newer. Would you be so kind Punkmeister to try debug build? Otherwise the problem that disturbs you in using Shareaza can remain undiscovered AS THERE IS NO BUG REPORT ABOUT IT, AND NO ONE KNOW WHAT IS IT ABOUT. If you will not change your mind, and no one else will report this bug it can realised you will have the same problem with oncoming 2.5.1.0 and again you will be disappointed. Now you have chance to try to fix it. Later you will have it also, but with debug builds after 2.5.1.0, awaiting for next official realise. uff.....

So beta is aviable for everybody - it is just called ddebug build.

Other thing is I was voting to launch it as 2.4.9.0 an RC of 2.5.0.0 (Release Candidate), so not full 2.5.0.0 yet. But my proposal has not been accepted.

[ailurophobe]

Having a Release Candidate for major updates might be a good idea. It can be difficult for users to understand why the amount of bugs increases when a going from debug builds to actual release. Realistically any major update comes with a real possibility that a bug fix release will be necessary. A release candidate system might make this clearer and easier to accept.

[ocexyz]

I think it could go this way:
After 2.4.0.4 when it was matured enough
publishing 2.4.9.0 as RC for testing etc. about from 4 to 1 month before
publishing 2.5.0.0 as Final Release (moment for all the glory etc.) about 4 month before
publishing 2.5.1.0 as upgread with all needed fixes.

If ther would be 4 monts (about of course) between them we would have 3 new versions a year. I think RC should be published for using and hence publick betatesting around V-VI (May-June), Final Release around X-XI (October-Novenber) and Upgread about I-II (January - February).

I suppose ppl will forgive bugs in RC, but will not in Final. I think current 2.5.0.0 is in fact RC.

[punkmaister]

[ailurophobe]

I'd prefer naming as "Shareaza 2.5 RC" release candidate followed by a "Shareaza 2.5" stable release and possibly "Shareaza 2.5.1.0" minor update. The relatively large period of time and amount of improvements between stable releases makes IMHO Shareaza well suited for using a release candidate system. In fact our major updates pretty much are release candidates in all but name already. A release build on the front page without known open bugs but also without extended public testing... That is what release candidate means, so we might as well start calling them that.

[punkmaister]

I'm glad that at the very least a release system is being considered. Had such a system being in place I probably would not be here complaining that is for sure. Well maybe but over very minor stuff like before. Honestly with all the troubles that this version has had they should just link the homepage to the latest build as there is no finalized build really at this point. 2.5 is not a finalized product. Maybe a release candidate but most certainly not the stable and fully functional platform one would expect of a finalized product. For the time being I'm stuck with the seriously downgraded 2.5 up till a Debug featuring a fully featured media player like it's predecessors comes around which probably will not happen in the foreseeable future.

[ocexyz]

[ailurophobe]

You are missing the difference between a release candidate and a beta. Beta is a feature complete version released for the purpose of getting rid of bugs. They usually have a list of known bugs. A release candidate is something that as far as the developers know is good enough to be released but has not been tested extensively enough to be sure if it is stable for all users. They usually have either no or only easily avoidable bugs at release. A beta is for beta testers, while a release candidate is for general users allowing much wider testing.

The difference between a release candidate and a stable release is that the users know there has not been enough testing to catch all bugs and do not have unreasonable expectations of it being bug free. So there is less complaining when bugs are found. It also makes giving bugfix releases to "stable" releases avoidable. In short, it just looks better.

Now that I am complaining, it would also look better from the end user point of view if debug builds were correctly labelled as either alpha or beta. Although this is less important since the pool of alpha testers and beta testers is currently the same for Shareaza. But if we are optimistic and expect having more devs, testers, and users in the future we might as well do it right before it becomes necessary.

[punkmaister]

Well whether BETA or Release Candidate the goal is one in the same, the difference being the potential number of users testing it. But either way is still not what one would call a finalized version. Anyway I haven't downgraded and do not plan too, I do plan to wait until a build that has a true faccisimile to the media player ShareAza used to have comes along.

[ocexyz]

Sorry I got enough of this discussion for now.

[acerswap]

Well, it would be good something like this:
-Official release.
-Bug fix version one month later.
-Release candidate one month later.
-Official release one month later.

Something like periodical updates.

[diztrancer]

Shareaza 2.5 was released with bunch of unsolved well-known bugs. Why ? Who knows.

OCE: You still try to avoid fact that 2.5.0.0 was launched when devs has found that are many reported bugs still unsolved ?

[punkmaister]

[ocexyz]

[mojo85]

Dude Shareaza is not a media player, get a grip. It's not a defunct implementation ... a couple of GUI issues and no Visualization support is hardly not something to throw a hissy fit over. It actually is more stable than the last, just because now we have code that can be fixed as opposed to a dll. Also because of the code, the future functionality of it is guaranteed to improve.

Now if Ryo can share with us the roadmap for the media player, is he done with th coding or are there plans to implement some of the old core functionality back. Also be productive ... list some of the missing features you see. Hopefully we can get an idea of what is currently missing including even the minor gui quirks.

[cyko_01]

[punkmaister]

[cyko_01]

[ocexyz]

There are advantages and disadvantages. Advantages of using older version is less bug, disadvantage is less possibilities and less adapted to current Internet conditions. Advantages of newer version is significantly better performance better adaptation to current Internet shape more possibilities fixed reported bugs, disadvantage is possibility to discover new bugs in new code.

I think to use all Shareaza power is better to use Debug version and update it at last once per week. This way I use most developed and actual code. During last 3 years I have noticed ONLY ONCE (1) a crash which has made ONE (1) of downloaded files to be unuseable anymore. I have seen many crushes and disadvantages of code which needed to be fixed - but I have reported them, so now Shareaza on my sys runs w/o problems, and really much better. Alos what I can do is to ask Feature Requests which in most of cases are treated seriously by devs, however in time devs have time.

And I remember I was really frightened to use Debug Build, also because this stupid warning at the start. I had to do this because of one bug to see if it was fixed. After I noticed differences I have decided to use Debug Builds, even I suffer from time to time a crash from a new code. But advantages are significantly bigger: new code performance is significantly better and I can have influence on how Shareaza work, so "pain in ass" can be eliminated by reporting problems to devs. This is much easier to ask to fix anything in Debug because Debugs are published everyday, but official releases only a few times in year, so any fixes must wait until all other bugs (not affecting me) will be fixed also. Consider this Punkmeister, please.

If one is from majority of users who don't have any problems then best is to use last stable official release. If one has noticed a problem or have some extra expectations from Shareaza, or future request, then I think wise choose is to use Debug Build till nearest new official release.

This is open project, like everything it got advantages and disadvantages. but always this is your free will whether you want it or not.