1. Indeed no flaming and constructive comments to get to a solution :)
2. I think always except minors as auto update (although this might
break... see 5)
3. As far as i have seen fixups rarely happen in offcial repo. Mostly it's
in the skinner's own repo.
4. For skins there should be a warning if user want to update. Depending on
what settings he has in 2.
5. Rollback aren't always possible. These only apply to the officially
download .zip file from repo. This won't fix it if the folder is cleared
when a user has modded his skin without making a backup.
example:
http://forum.xbmc.org/showthread.php?tid=132364
A rollback will only install the official .zip file not the modded one.
A possible solution would be to pack the current installed one into a .zip
and put that one as roll-back (yes this would be for the minute group of
users that mod skins).
Other idea would be to .zip the settings file along with the original .zip
package so when doing a rollback you are sure the old settings are still
available. This will allow some minor (needed) changes can be made to
settings.
Regards,
Martijn
On Sat, May 26, 2012 at 12:49 AM, Jonathan Marshall <
[email protected]> wrote:
> 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
>
>
------------------------------------------------------------------------------
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
