I shall have to disagree about the feasibility. I speak as a hobbyist developer with *very* little time for development (my professional career as a software developer lasted less than a year and it was 15 years ago).
Many people already have supported multiple versions, while the "pre" repos are open. It's not very different when done "constantly". Providing simple bugfixes for an old version while developing a "current" version with new features is not time consuming, as the (simple) bugfixes take almost no time and effort compared to developing new features. While the "pre" repos are open, you'd obviously leave all new development to the "pre" version and leave the old versions on their on, unless some critical update is needed, but mostly that would consider scrapers/weather addons and such. (How many times skins *break* with some external thing changing?) If the bugfix is not simple, don't do it, leave it broken and tell anyone complaining about it to update (manually). And in more general case, if you (as a skin/addon author) just don't want to support multiple versions the same time, don't. Nothing forces you to. But if an addon author would want to support multiple versions, he could, if something like this were in place. Anyway, perhaps there would need to be another, more flexible way than the version numbers to specify which updates are autoupdated, and which are left for manual updates. How about this: keep a "compability" number in addition of a version number. If a compability number was to change, then only update manually. If compability number of an update is the same as installed version, autoupdate. The compability number could be empty by default, then all updates autoupdate (like it is now, empty equals empty). So you could just not care about this at all, if you don't want to. -Viljo 2012/5/28 Martijn Kaijser <[email protected]>: > Agreed with spiff. > > I'm (and almost any one else) not gonna maintain several version of a plugin > within one XBMC release cycle. > > @Viljo > What you are proposing is just not feasible within an opensource community > where everything is build in their own spare time. > > Making too strict rules will scare of devs. > What Cory proposed is more realistic with the comments of ronie added. > Let's take it one step at a time before making any radical changes. > This is the first time something like this had happened (as i've heared). > > The only ones who come to the forum are the ones that complain. You will > almost never hear a happy customer. > > Martijn > > > On Mon, May 28, 2012 at 4:05 PM, Arne Morten Kvarving > <[email protected]> wrote: >> >> > To continue the windows analogy, you could stay on IE8 and get the >> > bugfixes, but you could also install IE9 and get all the new fancy >> > stuff and then get autoupdates for the new major version too - both >> > are supported on windows 7. >> >> the day we are a multi-billion company with *paid* skin devs, this >> might be close to realistic to expect. >> >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> Xbmc-addons mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/xbmc-addons > > -- Viljo Viitanen [email protected] ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Xbmc-addons mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/xbmc-addons
