Chocolatey-coreteampackages: (skype) Branch changed with no warning

[SidSmallwood]

As requested by @gep13 in comments on the gallery page, I'm raising this issue here.

A few days ago, the version of Skype installed by the Choco package was changed from 7.x to 8.x.

Unfortunately, this is not the uncontentious upgrade it might appear - Microsoft are maintaining two branches for the Skype code and the major version number represents them. The 8.x branch (what they are now calling "Skype for Desktop") is an entirely new codebase and was released still missing some of the features of the existing client (so-called "Classic" Skype). Many users are remaining on the 7.x branch, at least until feature parity is reached.

choco upgrade skype (or all) will silently switch users from the classic branch to the desktop branch. Not even Microsoft (who would presumably love everyone to be on the same client) are doing this: separate upgrade paths are being maintained, (That is, a "check for updates" on 7.x will not offer 8.x, but only a newer 7.x release.)

Ideally, two Skype packages would be available on chocolatey, SkypeClassic and SkypeDesktop, but in the absence of that I believe that this package should stick to the client version it started with.

[AdmiringWorm]

hmm, guess we could create a new package called skype-classic and leave the normal package as being the latest one available.

Should be easy enough to do with streams. I'll try looking into it in the coming days.

[SidSmallwood]

I would argue that this package should stay with the 7.x branch and the new package should be the one with the 8.x branch, because otherwise a number of users will be "upgraded" to something they aren't expecting - possibly something they've been steering clear of.

leave the normal package as being the latest one available

I don't think the usual numerical rules apply here - the "latest" release could be in either branch. 7.x and 8.x are essentially different products (both are receiving updates), not an older / newer release of the same thing. I'm sure in time MS would like / expect / force everyone to move to 8.x (and the Choco strategy should probably reflect that) but at the moment swapping between them is something even MS is leaving to users as an informed decision they need to make, not just doing it silently on upgrade.

[majkinetor]

I disagree.

Skype 8 replaces Skype 7 in the system when installed. The Microsoft intent is clear. You should pin the skype version.

We can create stream for skype if 7 is going to keep updating, but that will not help you. You can cup the v7 only with a method like to the one described here in function cinst-stream:

• https://github.com/majkinetor/au/issues/74

This should be integrated into choco IMO.

/cc @ferventcoder

[majkinetor]

One interesting idea comes to mind.
We could create metapackage that depends on older version of package 👏. I don't think we ever did that on purpose.

I still dont like it tho. You shouldn't cup all automatically anyway, that is on all operating systems recipe for disaster and will byte you for sure given enough time.

So I expect choco pin --stream ... to be the most elegant and universal solution.

[SidSmallwood]

Skype 8 replaces Skype 7 in the system when installed. The Microsoft intent is clear. You should pin the skype version.

I disagree. I think the replacement is more to do with the problems with having two different versions installed side-by-side.

I'm sure they would _like_ everyone to replace 7.x with 8.x, but their _intent_ in the narrower scope of what happens during an update is slightly different, although I do agree it's clear: the "check for updates" operation within Skype on the 7.x branch still only offers newer 7.x versions (and this has been the case well into the lifetime of the 8.x client).

So I expect choco pin --stream ... to be the most elegant and universal solution.

This seems perfect to me. I was unaware of this feature.

[SidSmallwood]

You shouldn't cup all automatically anyway, that is on all operating systems recipe for disaster and will byte you for sure given enough time.

I agree and I don't do it, but you know some people do. Others will see 18 packages to update and not notice that the Skype major version number has increased, or won't realise its significance. On the basis of the robustness principle, I'd have thought packages shouldn't try to catch people out!

[majkinetor]

This seems perfect to me. I was unaware of this feature.

There is just choco pin now that prevents app to be updated with cup all which is good enough for most cases. Stream option doesn't exist yet, I am proposing it now, or you can use my workaround.

I agree and I don't do it, but you know some people do

The same issue will happen on all other systems. Its well known fact on linux distributions too. Users shouldn't expect that total ignorance will do the job. If you allow automatic windows update for example, you will go the same route fairly soon. Actually, I installed Skype 8 because Skype 7 stopped working after latest windows update.

[majkinetor]

Also, cinst could support this in a manner like this:

• cinst Skype --with-minor-updates

This could mark the package internally. Example:

PS> cinst 7zip -wmu
7zip v17.1 succesifully instaleld

PS> cup all
...
7zip v17.1 is the latest minor version available but newer major version v18.5 exists
...

Brainstorming here, and this could be more flexible (for example not depending on terms like major/minor but be more precise like for example what bundler does).

[SidSmallwood]

Also, cinst could support this in a manner like this:

cinst Skype --with-minor-updates

This would be good in the general case, but I assume you are seeing this as something like pinning the major version and no more updates will be installed once that changes within the package. The issue here is slightly more nuanced, of course, with both 7 and 8 receiving minor updates simultaneously and this would mean that pinning isn't a very good option here either.

I've only skimmed the proposal you linked to, but I assume this scenario would be catered for by your streams idea.

[majkinetor]

I've only skimmed the proposal you linked to, but I assume this scenario would be catered for by your streams idea

You can use it now, it has nothing to do with streams, its just there because its related.

with both 7 and 8 receiving minor updates simultaneously and this would mean that pinning isn't a very good option here either.

Not sure what you think but no.

If we have 2 commands

• cinst <pkg> -wmu
• choco pin <pkg> --stream X.Y

Use case is similar but different.

First one is proactive. You say: I want current release, but I know that future versions may be problem for me, so I install it now and wan to receive only updates of the current major stream (this would work for tools following semantic versioning only)
Second one is reactive. You say: I know package will change soon, but I want to keep the current stream.

So, in your current case you would choco pin enable -n=skype --stream 7. and cup would install any new 7.x.y.z. versions. This is how cinst-stream function actually works.

[jberezanski]

@majkinetor

We could create metapackage that depends on older version of package (clap). I don't think we ever did that on purpose.

Yeah, this could work. The metapackage should depend on skype [7.0, 8.0), thus preventing upgrade to 8.x.

It's easier, at least for me, to type cinst skype-classic than to remember pin syntax.

[majkinetor]

Its still better to release this upstram.

I am also thinking about creating choco external addon for stuff like this.

Now that MS is involved into choco, it should have advanced options like this.

[ferventcoder]

@majkinetor I see you created an idea on AU and then here for a streams concept. Simply mentioning me is not the right way to propose a feature request, and I'm not the only one here that is going to weigh the idea - we have a community that buys into these ideas and they all expect those feature requests, bugs, etc to be on the official list/backlog. If it is not on the backlog, it is determined that maybe it doesn't have enough merit for getting it prioritized against the rest of other features that have been identified for being brought into the product, thus it won't be worked on ahead of those other things that have. I would go as far to say that until it gets into the backlog, you might expect it to get lost in the stream of everything else that is getting requested (see what I did there? ;) ).

If someone wants functionality to end up in Chocolatey, there are really two simple ways to get it onto the backlog:

1. Put it on the backlog directly (just file the issue at https://github.com/chocolatey/choco/issues/new) - you might want to discuss it somewhere else to form the idea a bit more, but then it needs to get on the backlog. Until it is on the backlog, it can't be prioritized and worked on. NOTE: I'm unlikely to be the one to do this for you, there are thousands of you, only one of me. I get hit by many, many emails per day pulling me in many directions, so it's a losing battle and fraught with disappointment if someone is hoping I will get it onto the list for them.
2. A paying customer puts in a bug report or feature request on a private channel and Chocolatey Software creates the ticket on their behalf.

That's it. Pretty simple. Super easy for folks. I hope this helps clarify what needs to be done if you hope to achieve seeing this get into Chocolatey itself.

So please go ahead and create that issue so we can prioritize it. It sounds interesting. Thanks!

[majkinetor]

Simply mentioning me is not the right way to propose a feature request, and I'm not the only one here that is going to weigh the idea

When I mention you, I do it for the following reason: for you to give initial few words (like you did here 'It sounds interesting'), maybe provide a link to existing discussion and give inital 👍 or 👎 so I can go and invest more time in creating a ticket on official repo, with more details, examples etc. I don't want to invest serious time into something that can be denied in few words.

So, this is right:

you might want to discuss it somewhere else to form the idea a bit more,

[mmikeww]

+1, i was surprised when choco upgrade put me on skype v8

[stale[bot]]

Dear contributor,
because this issue seems to be inactive for quite some time now, I've automatically closed it. If you still feel this is a valid issue, please feel free to re-open the issue. Thank you for your contribution.