Proposal for releases (1 Viewer)

[SpudR]

Firstly I must say that I'm NOT criticising anything - the recent release of 1.3.0 Alpha was a great milestone, this is just a suggestion I'm putting out there for discussion...

Don't shout at me for this suggestion!

Now, I think the release of 1.3.0 Alpha highlights a weakness in the process of releases, in that there are several 'killer' bugs IMO. So much so that I've dropped back to the previous release as [for me] 1.3.0 was unusable.
(Just to be clear - I've not submitted anything on these 'bugs' as they've all been reported by other already...)

Of course I realise that this is an ALPHA release and the bugs are kind of the point but the delay in releasing this seems to have been because of bugs which caused it to be unusable (obviously I'm not a member of the team so this is a huge assumption on my part) - in my case there were enough errors to make it unusable anyhow = little/no benefit for the delay (again I'll point out that I may be wrong in this assumption).

Also I think that the Alpha releases are viewed more as the next release of MP and not as a 'test' build.

So can I suggest that for future releases the community is strongly warned of the status of the release and it's put out there for community testing ASAP (once the current bug list has been addressed). Similar to what is done now but using the power of the great community here to harness the testing power of the many different set-ups in use for testing...

This test version would only be installable in a parallel manner (somehow detect that MP is already installed and uses many of the existing resources) so as to not disrupt the existing HTPC setup (so the significant other can still watch the soap operas!). Akin to the Chrome Canary idea - can only be installed as a secondary solution.

This should result in a faster, smaller release, another bug list being generated, another milestone to hit and a final release that has been thoroughly tested in many different scenarios.

Would this not speed up the development? It's fairly obvious that all scenarios for MP cannot be properly tested so why take the time?
Just release little and often in the test stages rather than the big list approach currently used.

Play nice please and discuss...

 

[SpudR]

No one?

 

[Holzi]

Just out of interest:
Which are the killer bugs for you?
Thanks!

 

[MrCrabs]

I like your idea and I laready read it once you posted it, but I thought this is more a discussion for developers - so I held back with my opinion.

The latest release of 1.3. Alpha took very long till it's release (at least it felt like) and maybe more little steps in seperate Alphas could increase developement speed.
Though I think I remember that the dev team once decided not release only big versions and before that you could get weekly builts of MP.

So maybe it is a good idea to go an intermediate way between weekly builts and only a hand full of releases a year.

I think the fact that the new git platform allows a dev to only integrate stuff that's working properly would come in handy. I know one can try out all the parts developed in Area51 but to many users it is not that easy.

Using the full manpower of the community by giving more releases to try out is a good idea.

 

[DJBlu]

Any alpha software released does come with a warning however most choose to ignore said warnings and think everything will be ok.

We could put up as many warnings on the download page and in the software and people will still install it on machines that they user every day.

The current system works as it allows for internal testing and then public testing. Show stoppers sometimes filter through hence the reason for testing.

If people are willing to risk installing on their machines that they use all the time then they should understand its not going to work. Saying I have had to go back to x.x.x version" isn't acceptable with alpha and beta versions. Release versions are there to use.

This is an evolving application and a little patience is required.

 

[Pat Clark]

There probably is a forum section for how to install and "back off" an alpha release without losing the previous release, but it would be helpful to consolidate it or point to it. I was able to back off with a full backup of ProgramData and Program Files, but I think a System Restore Point might be advisable as well. In my case, the blocking bug is the one related to multiple tuning details causing no card available.

I don't know whether it's reasonable to have a side-by-side alpha or beta installation like has been done for MP2, but it sure would be nice, and I think that's what SpudR is suggesting -- even if it has a new name, like MP1.3A or something, and would require a full re-install as MP itself when it's fully released.

 

[SpudR]

Thanks for the comments guys, most appreciated - I'm simply suggesting that the development for MP might be considered from a different angle.

I would envisage that running a side-by-side install for the tested version would be an option set within MP on startup - I'm fully aware that people will run the test version as the 'latest release' (can't account for stupidity). The new test version would only install with an existing MP installation and you'd have to choose the test version within MPConfig - with a rider that stated that this was alpha/beta etc...

How about showing a 'nag' screen that declares that this version is alpha/beta software (and you accept whatever, would you like to continue or return to the stable release yes/no), on a regular basis (say before every media play choice - choose music = nag, choose movies = nag, etc.) this will mean that people are fully aware of the status of the build and can return to the stable build if they wish.

 

[tourettes]

I would envisage that running a side-by-side install for the tested version would be an option set within MP on startup - I'm fully aware that people will run the test version as the 'latest release' (can't account for stupidity). The new test version would only install with an existing MP installation and you'd have to choose the test version within MPConfig - with a rider that stated that this was alpha/beta etc...

It will be quite hard when it comes to the config - only easy way would be to separate the configs completely, but it would require then 2x configuration effort for the people. Configs between different MP versions aren't always compatible (backwards and forwards) so people would run into random issues if the configs would be shared.

How about showing a 'nag' screen that declares that this version is alpha/beta software (and you accept whatever, would you like to continue or return to the stable release yes/no), on a regular basis (say before every media play choice - choose music = nag, choose movies = nag, etc.) this will mean that people are fully aware of the status of the build and can return to the stable build if they wish.

That would annoy any people who are willingly using the alpha / beta on production systems to provide more support for the development. And if we would allow that nag screen to be turned off then everyone would turn it off and it wouldn't have any use.

 

[SpudR]

All good pionts tourettes, but something should be done.
I think because the release schedule is a little slow, then the community and plugin/skin devs see the alpha as being the next release - this means that some plugins and skins get released as requiring the alpha software.
As an example (and I do love the skin), the Avallonis mod requires 1.3.0 for the latest version to work. Cul8er has the right idea though - he's releasing a 1.2.x compatible version too
For an example of a plugin, take the Smart Playlists plugin - I've got it installed but it's in the incompatible list as it's 1.3 only.
This means that those of us who like to keep up with MP, can't really do so.

I might be remembering through the rose tinted spectacles, but I don't remember this happening when the weekly SVNs were available (though I might be wrong ).

 

[mbuzina]

Any skin/plugin that targets 1.3 Alpha must be Alpha too, so the same is true for MP and skins&plugins, Alpha is the dangerous land you should only walk into if you know what to do (you don't just walk into an alpha build).

Also side-by-side is a great idea, but I guess it will be very hard for the tvserver component to work. The config issue is another one. Currently for me to, 1.3 Alpha is not prime time ready, but which alpha ever is? Remember the olden days with the nightly builds? Some people even had the install of them automated. So if they want to be on the bleeding edge, it is their issue.

As for Avallonis and 1.3.0: Since there is a rather large change in skin engine in this version, each skin dev has to fork his/her development. So cul8er prefers doing the new stuff first, that is OK for me, he will provide an update for the existing version too.

TL;DR; We will not invent a new development & release model that satisfies all needs, so let's stick to proven methods.