+1 here. It becomes much more crucial when you work with finely grained projects with each module in its own repo. Making a new release when you push a fix becomes too much of job to do.
On Tue, Sep 6, 2016 at 5:08 PM, Said Sikira via swift-evolution < [email protected]> wrote: > Yes, I agree that tags are far better option for production use, but > development process stage would certainly benefit from possibility to track > specific branch or commit. Having to rely completely on versioned tags in > development stage would not be easy nor very productive. > > Said > > On September 6, 2016 at 3:49:06 PM, Guillaume DIDIER ( > [email protected]) wrote: > > I think that the ability to fetch a branch or a commit may be interesting > (basically anything that git understands), would be nice, > but with the caveat that for production use it is far better to use à > fixed version (i.e. a tag). > We do not want that most packages are used by specifying the master branch. > > > *Guillaume DIDIER * > — > *ÉCOLE POLYTECHNIQUE* > 91128 PALAISEAU CEDEX > [email protected] > <[email protected]?subject=> > www.polytechnique.edu > — > > PS : I am new here, do not hesitate to correct me. > > Le 6 sept. 2016 à 15:41, Said Sikira via swift-evolution < > [email protected]> a écrit : > > Hi, > > Our code is almost always developed and pushed in small incremental > changes. When we implement critical amount of changes in our code, we push > new version. > > When adding dependencies to Package.swift file, we supply their repository > url and version we want to use. However, differentiating code only by it’s > version is not enough in some cases. When writing new code features, we use > branches. They enable all the mechanisms one needs to create, test and > deploy new features without polluting production environment. > > I think that Swift Package Manager should have support for branches (and > commits). There are several reasons why this feature would greatly improve > developer workflow: > > 1. Writing new features. Being able to specify branch in Package.swift > would make creating and testing new features easier. You wouldn’t need to > push new version to be able to use it in your Swift program. You would just > specify the branch you’re working on. > 2. Differentiating between new Swift versions. This problem comes from > the current Swift 2.2 -> Swift 3.0 migration. Many framework developers use > specific branches (swift–3, swift3.0) to work on migration of their API’s > to Swift 3. However, you can’t use them in your Swift projects because they > don’t live in the master branch in the repository. I’m sure this will also > happen when Swift 3 starts migration to the Swift 4, until ABI becomes > stable. > > SPM should also have support for specifying commits. Specifying which > commit you want to use in your project dependency is not always a good > idea, but it’s necessary in some cases. > > This shouldn’t be very hard to implement. We would need to update > PackageDescription and Get source from swift-package-manager repository to > enable specifying branches or commits. Pulling the branch source would just > be another parameter in git instruction. > > Example: > > // Specifying branch > let package = Package( > name: "SomePackage", > dependencies: [ > .Package(url: "https://repo-source.git";, branch: "new-feature") > ] > ) > > // Specifying commits > let package = Package( > name: "SomePackage", > dependencies: [ > .Package(url: "https://repo-source.git";, commit: > "c336664020v4f94ed78cbe7447a39ae5ca0b6c11") > ] > ) > > What are your thoughts on this subject? > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
