Page 11 of 11

Re: XMBC 2.18 Beta

Posted: Sat Dec 29, 2018 4:52 pm
by phil
OK 2.18 is now available to all.. Let the bugs roll in (I hope not!).

Thanks for your assistance and Happy new year to all!

Re: XMBC 2.18 Beta

Posted: Fri Jan 04, 2019 4:11 pm
by phil
OK so there have been three pretty high impact (but easy to fix) issues that have cropped up - not too bad but a bit of a shame - one of the problems of having so many configuration options is that covering every case in the beta program is unlikely!

Anyway, I'm going to release a 2.18.1 to correct these three issues...
The question is, do I built a beta before I do that (it will have to be called 2.19 beta 1) - Thoughts anyone?

Re: XMBC 2.18 Beta

Posted: Fri Jan 04, 2019 9:34 pm
by Kukurykus
I think there always should be place for X.XX.1 full version after newest is released. Then you can fix all bugs found in the first month they weren't detected during entire Beta phase. So maybe wait a moment still to be sure another problems won't show up or you have to release 2.19.2 ;)

You may release, 3, ...) Beta to test that what should finally close 2.19 works, before 2.19.1 :idea:

Re: XMBC 2.18 Beta

Posted: Sat Jan 05, 2019 11:53 am
by phil
Well for starters lets be clear, I'm not talking 2.19, I'm talking 2.18.1.
Even though I said that I would try and do more small releases, I'd still like to at least keep minor versions (the .19) for actual improvements and not just a few little bug fixes.

There are always a few things that crop up on release, because no matter how long the beta period is, the majority or people do not participate in the beta (which is fine, I'm lucky to have as many trying the beta's as I do - but its never going to cover all use cases).

I have fixed 4 relatively minor issues now and tested them as best I can on my two main machines. I can sit on it for a while longer but I'd almost rather know if my fixes work (don't break anything else) and then if required, make some little fixes and have a 2.18.2 release if demand is there. I certainly don't want to wait a month, not least because then it may interfere with my holiday in early Feb and also my signing cert expires sometime around Feb/March and that's always a pain to renew and I wouldn't like to have a big issue when the cert expires as I will be forced to wait to fix it then until the new cert comes through. Having said that, I'm aware that many people who use XMBC at work may not have been back to work since I released 2.18 (the lucky ones like me :)). So maybe holding off another week is a sensible thing to do!

For background info...
My versioning scheme is a little weird, because internally, the 2.19 beta 1 would be The 99 actually signifies "beta for the next minor version". Its done that way to make the update checks easier ( is lower than 2.19 but would be greater than 2.19 so the way it works now, if you had and I then released 2.19, it would think is > 2.19 and wouldn't offer you the release when doing an update check.). This makes it pretty much impossible to make a beta for 2.18.1 - although actually it wouldn't matter - if you are on 2.19 beta 1 if you are not told about the release of 2.18.1 as it would contain the same things, just with a beta label. Hence the possibility of building 2.19 beta 1 (v2.18.99.1) first.

Re: XMBC 2.18 Beta

Posted: Sat Jan 05, 2019 3:41 pm
by Kukurykus
Yes, certainly I meant 2.18 instead of 2.19. Only where I meantioned I could mean that or better 2.18.1 Beta, however now I think once Alpha is released, so 2.18 you should wait 2 weeks to release fixes so 2.18.1, and when there's need after another 2 weeks 2.18.2, what most possibly would be the last vers. before starting 2.19 Beta.

Good idea to force users to be Beta testers, but on the condition you won't give more than 3 new features per one minor release. After 2 weeks make fixes if needed, and when during next few weeks nothing was reported then release another 2-4 features (and so on), so like the first would be 2.19 (then if corrected 2.19.1), and then 2.19.2 (2.19.1 if not fixes were required after first update). You could also keep 2.19.1 (2, ...) for regular alphas, while between them something like (2, 3, ..) for fixing bugs (however probably would be first and the last, while maybe needed only sometimes). That could be then also named 2.19.1b (c, d, ...), while regular 2.19.1 (with new features only) would be 2.19.1a by default but with not displayed a letter. Of course the 4th number after 3rd dot could not work accordingly to that you said.

That would change probably Beta period for 2.19 as that would be released with Alpha is, by turns. So you could release 2.19 Beta in first instance up to (however you only used no more than for another beta updates), and then all collected ideas realease in 2.19 (alpha). The same for another Beta so 2.19.1 up to to finish by 2.19.1 (alpha). For now there was only Beta before you shared alpha, so this system should look like it.

I like your idea because that's true majority of users don't participate in Beta's, and I'm sure you won't be like Adobe which doesn't respect users. For the whole year from Alpha (that is in last years simply Beta!) they fix bugs they introduced together with new features, but not all, something like 70%, while they let live the rest of them. So if you followed your way and fixed fully everything right after that was released then your users wouldn't like those of Adobe products revert to previous full Alpha version while next one already is up from a yaer, but going finally to that another version (with plenty of fixes) when even newest got eventually released as well (again buggy that noone wants to use it).

Why you have to wait so long to get certificate, can't you ask of it a month before expiration, so you can have it when current one is about to be expired. Probably not - as you had to have parrarel version that would then turn into regular one :)

Re: XMBC 2.18 Beta

Posted: Sat Jan 05, 2019 4:39 pm
by phil
OK just to be clear, in "my" understanding of software releases, alpha's are internal (pre-beta)/ Then you get beta, which goes externally to selected users and then you get release. Release != Alpha! But that is just terminology... I think your points stand (when I decode the terminology :)...

I'm certainly *not* going to force users to be beta testers. I don't really like releasing a version then immediately having to fix it (hence the beta program) but I can't see a way to avoid all possibility of this... And to fix them in a minor update/patch release isn't a big deal. The question is should I push that patch release out to the beta testers before I push it out to everyone. And the answer to that depends on the amount of issues and how well I can test them my self to be sure they are now working (i.e. what are the chances the fix does not work or breaks something else).

If I push it out as 2.19 Beta 1, I can still build and release 2.18.1 which includes all the content of 2.19 Beta 1 - I just cant add any new features to the beta until I'm happy with the release... Or ideally, I have to start having a separate branch for release and beta and merge the changes between branches in my source control system (which Git is good at but I am not particularly familiar with!).

Regarding certs, Every time my cert expires, I seem to struggle to renew it. I use a polish company (Certum) and their English web site is confusing and not ideal. I think last year it wasn't too bad but the year before, they had to send me a hardware key (that cost me quite a bit) before the cert could be used... and that was a few weeks waiting for the post!

Re: XMBC 2.18 Beta

Posted: Sat Jan 05, 2019 5:15 pm
by Kukurykus
So probably I'm wrong, but that was for me logical that Beta (however next in the row) is something worse, unideal, yet so the product that must be tested & changed eanough to get the highest status (like amongst wolfs in the other direction) so the Alpha, that for me going this way always was equivalent to release.

By forcing users to be Beta tersters I meant doing it the way that doesn't make harm to them, so your idea of minor updates to releases would comply with this concept, as though you just said you would not like to fix newest bugs in no time, always that was something fresh for you that you knew its all aspects. Nothing hard to sort out at the moment, while the time spent on you could add to works on current features. Then you had free weeks before next ones ;)

Making Beta's and minor releases within short time is like doing the same twice. Probably you would avoid in 70% ceases during Beta something that you had problem with Alpha if introduced into in no time, so that still can work and bring less unwanted bad impresion to disappointed users, but I guess if they have to be only up to 3 features (or changes to them), that can be possible to give up Beta? You could keep Beta but only for some complex, completetly new and unpredictable features there is no chance they would work without many tests. If so then you can have Beta for them, otherwise for evyrthing simple you feel safe with you can skip Beta to go to minor release with them.

Leading Beta 2.19 and making another releases to 2.18 for another months looks weird for me, but I guess it's something your system require. I thought more like closing 2.18.x and then focusing on 2.19 only (Beta + releases). But that's of course something that in practise may not work, and you know that best ;)

I remember last year receiving certificate for XMBC - that was quite smooth of getting that, but I kept in memory what happened a year earlier and yes - hopefully that was one time crap occurance.