search

incuna / incuna-sass

Incuna's Sass Library
MIT License
2 stars 2 forks source link

Versioning #2

Closed perry closed 10 years ago

perry commented 10 years ago

Suppose that we have the following structure:

master - this contains all of the common ground web - adds IE stuff, other browser specific stuff edetail - iPad stuff epatient - not keen on this at all, but could be based on the web branch and contain some sensible defaults.

In theory you should never use the master branch, you would use one of the branches, but you would update it and version it accordingly.

How would the versioning work in a system like this?

master could be on v0.3, but since that change, several new features have been added to the web branch, bumping the version.

Would it be sensible having a changelog and versioning per branch?

Any thoughts @incuna/frontend @maxpeterson?

henrahmagix commented 10 years ago

If every project has its own application.sass or main.sass, we could package these all separately, meaning they would all be separate from master and simply add to your project, rather than branch from it. Then we don't have to worry about combining versioning, or merging between branches, since they'll all be treated separately. To keep the cost of private repos down, they could all live here, and thus have one issue tracker for the whole lot.

henrahmagix commented 10 years ago

Hm, but versions per branch might not be a good thing.

perry commented 10 years ago

Good idea on the multiple directories instead of branches.

Everything is packaged up for build, so it would only be in development that redundant styles are hanging around.