Skip to content
This repository has been archived by the owner on Sep 16, 2019. It is now read-only.

Semantic Versioning #395

Closed
justinpage opened this issue Jul 28, 2015 · 9 comments
Closed

Semantic Versioning #395

justinpage opened this issue Jul 28, 2015 · 9 comments

Comments

@justinpage
Copy link
Contributor

Since we are embracing composer, we should adapt semantic versioning.
Advantages are described at http://semver.org/

@olefredrik
Copy link
Owner

As this is a starter-theme based on Foundation, I thought it would make sense to version the project with the same version number as the Foundation version that it's based on at any time. I can not quite see the benefits of moving away from that?

@justinpage
Copy link
Contributor Author

Depending on how strict we are with semantic versioning, every minor update that improves the software will cause a number to go up. Since this project evolves with different dependencies as well as future pull requests that may fix known issues, it might make sense to have our own semantic versioning to keep identity on what has changed within this product.

If we allowed ourselves to follow release versions from Zurb's Foundation, we would be at the mercy of their release cycles. In other words, if their current release is, say 5.1.1 and ours is also 5.1.1, but a major bug is discovered in this repo that needs fixes, then we would be force to update dev-master. However, we won't be able to declare this as 5.1.2 or whatever number until Zurb releases their next version. This also creates a burden on you to follow every single release. Again, it depends how strict you are.

Some alternatives would be to begin at 1.0.0 --establishing that 1.0.0 uses version 5 of the framework. Another option, if you are determine to follow the same number, is a hybrid 5.0.0 tag release --communicating that this framework uses 5.0 of foundation. However, you still maintain patch and minor releases that do no have to be at the discrepancy of Zurb.

Again, this is your call as I only have a handful of projects that we use semantic versioning. Some we follow more strictly than others.

@olefredrik
Copy link
Owner

You're probably right. I like the idea of beginning at 1.0.0, establishing that 1.0.0 uses version 5 of the framework. I also like the idea of a hybrid 5.0.0 tag release, communicating that this framework uses 5.0 of foundation. Let's keep it open for a little while.

It should only be a matter of weeks before zurb release vesion 6.0 of foundation. I think that it would probably be a good idea to tag the repo with the most current version 5 release, just before starting the upgrade work to foundation 6. Then it would still be possible to download FoundationPress based on Foundation 5, for those who require that. Don't know. Haven't got to much experience with this stuff, to be honest. Learning by doing (and talking to clever people like you), I guess :)

@Aetles
Copy link
Contributor

Aetles commented Aug 3, 2015

It makes sense what KLVTZ says, there has been a lot of major changes in FoundationPress as a theme that changes template files, functions, file structure and even workflow (like the change to npm run) without any change in version name. Sort of a constant moving target. Since it is meant to be used as a starter theme only it is ok to break backward compatibility and change a lot of stuff but the version number could give users a nice hint of how big the changes are.

On the other hand, the popular starter theme Underscores have chosen to be a non-versioned theme:

I'd prefer to look at _s as a non-versioned theme that keeps getting rolling updates to its V. 1.0.

(As always, it up to the maintainer, users of FoundationPress are probably well aware of the pace of changes by now, I know I am.)

@Luciaisacomputer
Copy link
Contributor

Maybe having a section for most recent changes could help? I know that we can look at the changes in the repo but having a quick overview of what is different could help as well. Most of the time it is obvious like when the templates folder and most of those page templates were moved, but when there is a decent change, having a quick overview of that might be useful.

@justinpage
Copy link
Contributor Author

@LukePettway do you mean a changelog? That would be a super helpful idea! I believe that would come in conjunction with version releases. Yoast does a good job in setting an example:

https://github.com/Yoast/wordpress-seo/blob/trunk/changelog.txt

@Luciaisacomputer
Copy link
Contributor

@KLVTZ , I guess that's what I meant haha! For the projects I work on, I may go a few weeks to a month without getting a new FoundationPress install going, so having a quick overview to know what new features have been added would be cool.

@justinpage
Copy link
Contributor Author

@LukePettway for sure! Since you had the great idea, be sure to make a new issue for adding a changelog. I think it's a great addition for any repo!

@olefredrik
Copy link
Owner

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants