A couple of comments on this:
1. First off, great discussion by all.
2. Skins are such a personal thing (both to the designer but often more so
to the user) that we need to ensure that the user has more control over the
process of updating. One method would be to change the auto-update switch
to never/minor revisions/major revisions and default it to minor-revisions.
3. If 2 is done, we need a policy in place as to what is a minor and what
is a major revision - it doesn't have to be burdensome, just something we
all agree is best practice. I suspect most already use major.minor.fixup
numbering anyway in revisions, so this should be easy enough to implement
across the board. Reviewers would need only check that the minors don't
contain major changes.
4. Even with the above in place, I think we need a re-think of how the
current skin is updated. I'd suggest that this should always be precluded
from auto-updates, thus always giving the user a choice.
5. Lastly, rollbacks are already possible, and should be possible without
breakage regardless of version changes between major XBMC releases. This
requires skin settings in particular to not change meaning between
versions, but that is needed anyway for a clean update path (obviously no
resetting of all settings - that builtin should not exist full stop).
Note that 2 and 4 are XBMC-side changes, so we cannot do anything about
this with respect to Eden. Let's keep the discussion going, though, so
that Frodo handles this in a nicer way.
Cheers,
Jonathan
On Fri, May 25, 2012 at 2:19 AM, jingai <[email protected]> wrote:
> Another thing that would help a lot would be to allow users to hold
> specific versions of addons. In general, I want automatic updates enabled,
> but sometimes I would like to hold a specific addon that I know behaves in
> a way I don't like.
>
> It would also help in the case that a user makes local changes they don't
> want overwritten. That's not really a good practice, but users do it all
> the time, particularly with skins. Usually it's because they really want a
> given feature that the addon/skin author won't get around to implementing
> for a while.
>
> Could take it one step further and do it like aptitude does, allowing not
> only indefinite holds, but also temporary holds that release when the next
> version comes out.
>
> I personally think that these changes -- plus the warnings to the user as
> Jezz and Amet mentioned for "major" updates -- would solve the problem
> entirely without limiting the skin authors' creativity/freedom.
>
> -j
>
> On May 24, 2012, at 2:59 AM, Zeljko Ametovic wrote:
>
> > if after the roll back user still gets the "old" look and settings than
> all is fine IMO.
> >
> > I think we should not limit the skins to a guidelines, they will all end
> up looking the same we should give authors freedom to do anything they want.
> >
> > update process could be made a bit cleverer by only auto-updating
> maintenance versions (1.0.x) and asking in case of minor and major bumps.
> >
> > this is all coming from someone who hasn't changed the skin since 2009
> so feel free to ignore me
> >
> > cheers,
> > amet
> >
> > On Thu, May 24, 2012 at 10:33 AM, Martijn Kaijser <
> [email protected]> wrote:
> > Also agree on this.
> >
> > A skin is still a 3rd party app this is installed and maintained outside
> the scope of XBMC.
> > If removing features isn't allowed this is starting look like Apple
> store...
> > Users will always complain what ever you do (forum is full of examples).
> >
> > I think the idea of Jezz_X is good.
> > For every major revision pop-up a dialog that tells the user a major
> update is available and he might loose some of his customization.
> > Loosing a skin they like isn't the end of the world cause they are
> replaced with something 'simulair' or even better.
> > Perhaps they complain the first week however after that they probably
> don't even remember. Like already said this happens perhaps once a year?
> > Eden isn't released that long ago so you can still see this as a final
> release that belongs to that release and the 2.0 version was more a
> pre-Eden skin.
> >
> > Limiting skinners (and perhaps scripts) in the creative proces to
> provide users with a better and easier to use skin is wrong IMO.
> >
> > Small note:
> > We (the ones in this mail thread) are in no way even representative for
> the actual user opinion.
> > Having a poll about this on the forum wouldn't even be representative as
> well.
> >
> > regards,
> > Martijn
> >
> >
> >
> > On Thu, May 24, 2012 at 4:30 AM, Philipp Temminghoff <
> [email protected]> wrote:
> > disagree.. if the skinner thinks he can replace a view / widget /
> whatever with something better he should be allowed to do that. and if he
> thinks a feature is superfluous, he should also be allowed to remove it.
> > as ronie said, it´s just annoying to work with a skin if you are not
> allowed to make it look / behave how you want it to.
> >
> > On May 24, 2012 4:21 AM, Cory Fields <[email protected]> wrote:
> > Jezz: "No functionality should be removed" only applies to automatic
> > updates. Neither of your examples fit in that case.
> >
> > Maybe I should clarify, this is an example of what I consider to be a
> > violating change:
> >
> > 1. User configures the views they like
> > 2. Automatic update is applied that removes a view.
> > 3. User no longer has the view they liked.
> >
> > Surely we can all agree that's rude?
> >
> > Let's set config and resetting to defaults aside for now and focus on
> removal.
> >
> > Cory
> >
> >
> ------------------------------------------------------------------------------
> > 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
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > 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
> >
> >
> >
> ------------------------------------------------------------------------------
> > 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
>
>
>
> ------------------------------------------------------------------------------
> 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
>
------------------------------------------------------------------------------
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
