Add Release on master branch

[broadway]

Add Release on master branch

[cordoval]

👍

[mbadolato]

There already are two tags (0.1.0 and 0.1.1)

[macintoshplus]

I do not know how are managed versions but it seems appropriate to put versions.
Put a dev-master in composer.json a project into production does not seem like a good practice!

I would have loved a 0.1.2 version before removing the UUID generator ;-)

[cordoval]

cannot agree more with you @macintoshplus, people think that following even the branch alias is fun. No it is not and that is why the bugfix third number exists in semver. It is not like that will prevent to have a proper long haul release. A release is not about how much bugfixes you have in them, it could actually be several bugfixes leading into a minor release or a major release. But again conservadurism (imo) gets in the way imo.

[Miliooo]

I would have loved a 0.1.2 version before removing the UUID generator ;-)

Agreed. I have no problems with BC breaks, I event voted +1 for some of them. But having a new tag before doing one seems like a sane way of handling them.

[mbadolato]

Agreed that a change like the UUID piece should have warranted a new tag.

However, @macintoshplus, like I said, there are current tags. The installation instructions even state:

composer require broadway/broadway ~0.1.0

So you shouldn't have dev-master in your composer.

Granted, you won't get the latest changes (like the UUID split) until there's a new tag and you run composer update, but you are able to lock your versions to where your code works, which is your whole point. 😄

[macintoshplus]

I prefer "broadway/broadway": "0.1.2" that "broadway/broadway": "dev-master#2eb0c0978d290a1c45346a1955188929cb4e5db7" in my composer.json.

My request is exactly about adding tag order to obtain some of the changes to the master branch.

I would do with.

[wjzijderveld]

We just tagged 0.2.0 after we merged 2 more PR's with BC breaks.
We also updated the branch alias to 0.3.x-dev

But at this moment it isn't really feasible to tag before each BC break, as almost every PR at this point still breaks BC. So between 0.1.1 and 0.2 multiple BC breaks were merged before tagging. You should expect the same to happen between 0.2 and 0.3. If you worry about BC breaks, then don't use the branch alias.

[macintoshplus]

Thanks

[cordoval]

I think you should move the branch alias to 0.2.1 perhaps? since it is more conservative. If production code locks it into 0.3.0 and then there are one or more releases before 0.3 then for someone that was locking it with ~0.3@dev trying to follow the master branch would be a nightmare. But yeah a lot of people use branch alias unfortunately.

[stof]

@cordoval given that BC breaks gets merged into the master branch, using 0.3.x-dev as branch alias is better than 0.2.x-dev. anyone using ~0.3 now are explicitly asking to be on the unstable version, so they are asking for BC breaks to be applied to their code.

[cordoval]

yes even imo more semver proper it should be ~1.0.0 or ~2.0.0 but again it boils down to some mindsets not wanting to get a big number only "we like what we have" approach which has nothing to do with semver.

[sstok]

Actually mentions that unstable software can use the 0.y approach.

How should I deal with revisions in the 0.y.z initial development phase?

The simplest thing to do is start your initial development release at 0.1.0 and then increment the minor version for each subsequent release.

http://semver.org/