search

iziteq / izi-api-schemes

JSON Schemes for IZI.API validation
2 stars 2 forks source link

Use semantic versioning #4

Open bartfeenstra opened 9 years ago

bartfeenstra commented 9 years ago

Would you mind using semantic versioning to version this project? That way we can use Composer (for which integration was just added) to pull in the correct version very easily. Semver is an industry standard and other package managers such as NPM and Bower use it as well.

Sutharsan commented 8 years ago

tl;dr Please use tags to mark the releases.

I noticed that currently branches are used, one per patch version, that is a good start, but when using Composer to checkout the project it will checkout the head of the branch. And more than that, it will clone the complete repository, checked out at the head of the selected branch.

The alternative, one that I strongly advise, it so use tags to mark releases. When tagging a release, Composer checks out only the tagged release and does not clone the complete repository. This is more efficient (less files, faster download) and exactly what is needed for a production environment.

Bringing branches and tags together, offers the best of both world. Use branches for major and minor version, tag (patch) release versions. Developers use branches in their composer.json, for production environments, tags can be used. The cutting edge git clone for developers, the predictable tag for production. Bug fixes can be released in their appropriate branch and result in a new patch release. Which is easer for developers and better matches the idea of semantic versioning. 

branch 1.2 --+---------------+------------.--+---------------
             | tag: 1.2.0    | tag: 1.2.1  \  | tag: 1.2.2   ^ head
                                            \
branch 1.3                                    --+---------------+--------------
                                                | tag: 1.3.0    | tag 1.3.1    ^ head
aab101 commented 8 years ago

Thanks Sutharsan,

Totally agree with you, we were/are going to follow this way, however, current versions were behind of actual implementation and we decided to use branches way first to periodically passing real production requests against all versions. Next weeks (at least in October), we plan to merge all branches to master and set correspondent tags continuing development on 'develop' branch.