Tag a release

[zanderwar]

Hi Verot,

Could you please tag a release, composer is a little weird when it comes to requiring a package using dev-master

Some companies are in a sticky scenario where they have no choice but to include the vendor folder in a git repo and in our scenario... we can't afford the time it takes to composer install.

A package that's been required using version dev-master appears in the repository completely empty with only a single commit hash as a reference. This is because composer assumes you will be calling composer install at some point, and then composer will use that hash to download everything from dev-master up until and including that hash

So yeah with that said; we're hoping that you're willing to tag a 1.0 release

[zanderwar]

FYI: I've had to fork this repo, namespace it, tag a release and add it to packagist as a workaround that I hope is temporary. I see several requests regarding namespacing and releases none of which have come to fruition. https://packagist.org/packages/zanderwar/class.upload.php

This repo has 279 forks but only 10 contributors so it goes without saying that a tagged release/namespacing is in high demand

[verot]

Hello. I have namespaced the class, and created releases.

Can you confirm that it is all correct on your end?

[zanderwar]

Hey!

Excellent glad you're on board with it! Tagging is annoying

So a few things, composer implores that you follow semver.org (semantic versioning)

The versions should become:

0.33.0 -> 1.0.0 0.34.0 -> 1.1.0 0.35.0 -> 1.2.0 0.36.0 -> 2.0.0 - breaking changes occurred so the MAJOR needs to increment

In the first 3 releases you have php: >=4 this should become php: >=4 < 5.3 to prevent people from installing this version if explicitly requested and it doesn't match their dependencies

Why the version changes?

Take the following installation line:

composer require verot/class.upload.php

This is going to find and install version 0.36.0 (if your systems PHP is >= 5.3) but it's going to require it as ^0.36.0 which is telling composer that in future; it's perfectly safe to install all versions between 0.36.0 and 0.9999.9999 and that it won't break anything (hence semver, the only time it would break is if the MAJOR version changed)

Nothing worth panicking about, your versioning is still valid per-say; but it does have its holes. I would strongly recommend to delete your releases and retag them as above.

If the above was TL;DR then follow this:

1. Delete all your releases (dont worry about packagist just yet)
2. Revert everything so that it's at where it was yesterday
3. Once reverted, create a branch from master called 1.*, this new branch will be used to accept new PR's for the v1.0.0 -> v1.9999.9999 range
4. Create/tag a release from the 1.* branch called 1.0.0
5. HALF DONE - That's version 1 completely safe now (php >=4 <5.3)
6. Update your master branch to use namespaces
7. Update master composer.json to include the restriction: "php: >=5.3"
8. Create a branch called 2.* from master
9. Create/tag a release from the 2.* branch called2.0.0`
10. Master is now considered your 2.*-dev branch

So now we have two branches that represent released versions, when someone wants to submit a PR they can select the branch they want to merge their PR into - It's of course up to you if you want to accept it but just make sure to continue to follow semantic versioning....

Lets, for example, say that someone has come along with a decent PR that you must have and they're requesting it to be merged into your 2.* branch. You should:

1. Check if its a breaking change, if it is; and you want it; it should be merged into master in preparation for a 3.0.0 tagged release if it's not possible to make it backward compatible
2. If it's backward compatible, it SHOULD be merged into 2.* and a release should be tagged as 2.1.0
3. If it's a bug they've fixed (aka a patch), then it should be merged into 2.* and a release should be tagged as 2.0.1

It can be confusing at first, but it's well worth it and highly respected. Master should always be treated as the "future version"

I'm happy to do all of this for you; but I'd obviously require collaborator status on this repo.

I'm not entirely sure why you have 4 releases at the moment, from what I can see only 2 should be out

---

After all is said and done, head over to packagist and delete your obsolete versions

[zanderwar]

Perhaps send me an email at reece.alexander@gmail.com with your skype name and we can get through it step by step together :)

This probably conflicts with your current releases on your website, so ultimately this is optional, a dev can choose to install the relevant version and lock it to that version; this is just the ideal way of going about things whilst also giving you the ability to easily update earlier versions

[verot]

Hi. I have done what you suggested.

• A branch 1.x, compatible with PHP4, with tags such as 1.x.x. In this branch, I will commit PHP4-only changes, and I will cherry-pick commits from master if they apply.
• A branch 2.x, compatible with PHP5.3+, with tags such as 2.x.x. In this branch, I will merge commits from master as long as they are not a breaking change, and then after that I will cherry-pick commits from master if they apply.

Is that all good?

[zanderwar]

Beautiful! Thanks a bunch verot

Cheers