Hi all,
> On 31 Oct 2016, at 21:23, Anders Bertelrud via swift-evolution
> wrote:
>
> * What is your evaluation of the proposal?
-1
> * Is the problem being addressed significant enough to warrant a change
> to Swift?
Yes, this is significant problem that basically prevents Swif
Unfortunately, I'm not convinced that semantic versioning would help here. It
could have been different if any of the tools in Apple's ecosystem and other
ecosystems emphasized semantic versioning from the start.
I also strongly agree with issues highlighted by Orta, specifically with:
> Update
The other point is that when working in a multi-language environment, having
conventions such as this broken causes additional mental burden. That is, after
working with JavaScript/Rust/iOS with CocoaPods and then switching to Swift,
would require a lot of unneeded context switching, as in: "Whe
I also agree with the point that .lock extension better suits here and adheres
to a convention already established in other languages. I personally would
prefer the file to be named Package.lock, not Package.pins and also think that
it would help newcomers who already used other package managers
I also strongly agree with this, I'd prefer version pinning to happen by
default, rather than with explicit command as it will make builds reproducible
by default.
I totally agree that we can rely on past experience with other package managers
(npm being the case), where pinning with a separat
Hi Daniel,
I hope this proposal really is still in active review, as it is marked as such
in the swift-evolution Git repository.
I did a quick reading of this proposal and I like it very much. I think that it
provides a solution that is additive and doesn't break any existing package
specifica
-1. I strongly oppose this proposal and think that it adds substantial
complexity to the language with introduction of yet another set of keywords
that are similar to `final` and visibility modifiers, but work differently.
The proposal doesn't cover the behaviour of `final` and having `final` and
`
