New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Semver #261

Closed
adrienbrault opened this Issue Sep 18, 2013 · 31 comments

Comments

Projects
None yet
@adrienbrault

adrienbrault commented Sep 18, 2013

Hey,

I am really surprised to notice that there is not tag/branch alias on packagist.
Could you start tagging releases, have branch aliases etc please ?

@mageekguy

This comment has been minimized.

Show comment
Hide comment
@mageekguy

mageekguy Sep 19, 2013

Contributor

There is no tag because (in theory) all "versions" are backward compatible.

Contributor

mageekguy commented Sep 19, 2013

There is no tag because (in theory) all "versions" are backward compatible.

@Ocramius

This comment has been minimized.

Show comment
Hide comment

Ocramius commented Sep 28, 2013

@gauthier

This comment has been minimized.

Show comment
Hide comment
@gauthier

gauthier Oct 2, 2013

Contributor

@mageekguy I noticed you added quotes around "versions" ; anyway, @adrienbrault is right - there is actually no version in atoum.

Even if there is no BC breaks (at this time) from a commit to another (really ?? ;)), the biggest issue is related to documentation: if you don't identify software versions, there is no way to have a documentation for each commit.

I don't think that forcing users to update atoum each and every time a contributor pushes something in the repo is a very good idea. By the way, as long as you don't version atoum, you just cannot afford BC breaks, although they will appear eventually.

Contributor

gauthier commented Oct 2, 2013

@mageekguy I noticed you added quotes around "versions" ; anyway, @adrienbrault is right - there is actually no version in atoum.

Even if there is no BC breaks (at this time) from a commit to another (really ?? ;)), the biggest issue is related to documentation: if you don't identify software versions, there is no way to have a documentation for each commit.

I don't think that forcing users to update atoum each and every time a contributor pushes something in the repo is a very good idea. By the way, as long as you don't version atoum, you just cannot afford BC breaks, although they will appear eventually.

@adrienbrault

This comment has been minimized.

Show comment
Hide comment
@adrienbrault

adrienbrault Oct 30, 2013

$ composer update
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - hautelook/frankenstein 0.1.1 requires atoum/atoum dev-master -> no matching package found.
    - hautelook/frankenstein 0.1.0 requires atoum/atoum dev-master -> no matching package found.
    - Installation request for hautelook/frankenstein ~0.1 -> satisfiable by hautelook/frankenstein[0.1.0, 0.1.1].

Potential causes:
 - A typo in the package name
 - The package is not available in a stable-enough version according to your minimum-stability setting
   see <https://groups.google.com/d/topic/composer-dev/_g3ASeIFlrc/discussion> for more details.

Read <http://getcomposer.org/doc/articles/troubleshooting.md> for further common problems.

Awesome that I need to require a non stable version of atoum in every project.

adrienbrault commented Oct 30, 2013

$ composer update
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - hautelook/frankenstein 0.1.1 requires atoum/atoum dev-master -> no matching package found.
    - hautelook/frankenstein 0.1.0 requires atoum/atoum dev-master -> no matching package found.
    - Installation request for hautelook/frankenstein ~0.1 -> satisfiable by hautelook/frankenstein[0.1.0, 0.1.1].

Potential causes:
 - A typo in the package name
 - The package is not available in a stable-enough version according to your minimum-stability setting
   see <https://groups.google.com/d/topic/composer-dev/_g3ASeIFlrc/discussion> for more details.

Read <http://getcomposer.org/doc/articles/troubleshooting.md> for further common problems.

Awesome that I need to require a non stable version of atoum in every project.

@marmotz

This comment has been minimized.

Show comment
Hide comment
@marmotz

marmotz Oct 30, 2013

Contributor

Atoum is stable. It is not versionned. It's not the same things

Contributor

marmotz commented Oct 30, 2013

Atoum is stable. It is not versionned. It's not the same things

@adrienbrault

This comment has been minimized.

Show comment
Hide comment
@adrienbrault

adrienbrault Oct 30, 2013

Then it should somehow be stable in composer.

adrienbrault commented Oct 30, 2013

Then it should somehow be stable in composer.

@marmotz

This comment has been minimized.

Show comment
Hide comment
@marmotz

marmotz Oct 30, 2013

Contributor

Composer doesn't like not versionned software. Too bad. Atoum has not to adapt itself to an other software.

Contributor

marmotz commented Oct 30, 2013

Composer doesn't like not versionned software. Too bad. Atoum has not to adapt itself to an other software.

@Ocramius

This comment has been minimized.

Show comment
Hide comment
@Ocramius

Ocramius Oct 30, 2013

@marmotz we'd need a stable version as well to use autom.

No tags = not stable.

Note that this is not about composer itself, but valid generally.

Ocramius commented Oct 30, 2013

@marmotz we'd need a stable version as well to use autom.

No tags = not stable.

Note that this is not about composer itself, but valid generally.

@marmotz

This comment has been minimized.

Show comment
Hide comment
@marmotz

marmotz Oct 30, 2013

Contributor

You need a stable version of atoum ? Cool ! We just released a brand New stable version !... On master branch...

Seriously, I want tags too. I have already say that to @mageekguy. But, i use atoum without tags in all my projects and I sleep at night anyway !

Contributor

marmotz commented Oct 30, 2013

You need a stable version of atoum ? Cool ! We just released a brand New stable version !... On master branch...

Seriously, I want tags too. I have already say that to @mageekguy. But, i use atoum without tags in all my projects and I sleep at night anyway !

@Ocramius

This comment has been minimized.

Show comment
Hide comment
@Ocramius

Ocramius Oct 30, 2013

@marmotz that's because autom is a testing framework, and not part of your core logic. I wouldn't ever use it in my software directly without having a clear separation of versions.

It is a documentation, stability and trust issue. You can't trust a software that is not providing meaningful version bumps in case of changes (yes, changes are always there!).

That's what the issue is about, and I 100% agree on it.

Ocramius commented Oct 30, 2013

@marmotz that's because autom is a testing framework, and not part of your core logic. I wouldn't ever use it in my software directly without having a clear separation of versions.

It is a documentation, stability and trust issue. You can't trust a software that is not providing meaningful version bumps in case of changes (yes, changes are always there!).

That's what the issue is about, and I 100% agree on it.

@mageekguy

This comment has been minimized.

Show comment
Hide comment
@mageekguy

mageekguy Oct 31, 2013

Contributor

@marmotz: good night ;).

Contributor

mageekguy commented Oct 31, 2013

@marmotz: good night ;).

@alexandresalome

This comment has been minimized.

Show comment
Hide comment
@alexandresalome

alexandresalome Oct 31, 2013

This should work with a minimum-stability at stable.

{
    "require": {
        "atoum/atoum": "dev-master@dev"
    }
}

Here, you explicitly give expected stability.

Semver is another debate, but the atoum principle is compatible with stability requirements in composer.

alexandresalome commented Oct 31, 2013

This should work with a minimum-stability at stable.

{
    "require": {
        "atoum/atoum": "dev-master@dev"
    }
}

Here, you explicitly give expected stability.

Semver is another debate, but the atoum principle is compatible with stability requirements in composer.

@willdurand

This comment has been minimized.

Show comment
Hide comment
@willdurand

willdurand Nov 4, 2013

Seriously? Relying on SHA ids to identify two different versions is just dumb, and that is what you are encouraging! Sure it is BC, so what? Does that mean we need to manually stick to a version by using a commit id rather than a tag, which is by the way, its main role?

Let me rephrase, what if you introduce a BC break in your master branch? Don't tell me that it won't happen because we never know ("[...] in theory [...]").

Following semantic versioning helps your users know about new features, bug fixes and even BC breaks. So please consider using it or at least create some tags for those who care about version constraints.

willdurand commented Nov 4, 2013

Seriously? Relying on SHA ids to identify two different versions is just dumb, and that is what you are encouraging! Sure it is BC, so what? Does that mean we need to manually stick to a version by using a commit id rather than a tag, which is by the way, its main role?

Let me rephrase, what if you introduce a BC break in your master branch? Don't tell me that it won't happen because we never know ("[...] in theory [...]").

Following semantic versioning helps your users know about new features, bug fixes and even BC breaks. So please consider using it or at least create some tags for those who care about version constraints.

@omansour

This comment has been minimized.

Show comment
Hide comment
@omansour

omansour Nov 4, 2013

I am a big fan, user and very small contributor to atoum but, as a manager off a large team depending on atoum to secure my deploiement, I will appreciate tagged versions.

okay, its BC compatible and we are in version 1.0.123461 so what ... faite moi plaisir :)

omansour commented Nov 4, 2013

I am a big fan, user and very small contributor to atoum but, as a manager off a large team depending on atoum to secure my deploiement, I will appreciate tagged versions.

okay, its BC compatible and we are in version 1.0.123461 so what ... faite moi plaisir :)

@marmotz

This comment has been minimized.

Show comment
Hide comment
@marmotz

marmotz Nov 4, 2013

Contributor

@omansour, you can use "dev-master" tag. It's a special tag just for you :p

Contributor

marmotz commented Nov 4, 2013

@omansour, you can use "dev-master" tag. It's a special tag just for you :p

@Ocramius

This comment has been minimized.

Show comment
Hide comment
@Ocramius

Ocramius Nov 4, 2013

@marmotz trolling users like that is not useful.

If this is not going to happen, then fine - you can close the issue, get your negative feedback, tweets, blogposts, whatever and that's it.

Keeping the issue open and using it to mock people suggesting well known, good and well accepted software development practices won't help anyone.

At least we'll know that there's no intention of fixing the (actually existing) problem

Ocramius commented Nov 4, 2013

@marmotz trolling users like that is not useful.

If this is not going to happen, then fine - you can close the issue, get your negative feedback, tweets, blogposts, whatever and that's it.

Keeping the issue open and using it to mock people suggesting well known, good and well accepted software development practices won't help anyone.

At least we'll know that there's no intention of fixing the (actually existing) problem

@stephpy

This comment has been minimized.

Show comment
Hide comment
@stephpy

stephpy Nov 4, 2013

Member

Following semantic versioning helps your users know about new features, bug fixes and even BC breaks.

+1, that's why we are loving tags. x.y.z Everybody understand this format.

The main raison some users dislikes this format is because they'll have to backport bugfixes to previous versions and it's a big work ... But i would prefer to use tags and have “dev-master philosophy“ (maintain only last release) than NO TAGS.

Member

stephpy commented Nov 4, 2013

Following semantic versioning helps your users know about new features, bug fixes and even BC breaks.

+1, that's why we are loving tags. x.y.z Everybody understand this format.

The main raison some users dislikes this format is because they'll have to backport bugfixes to previous versions and it's a big work ... But i would prefer to use tags and have “dev-master philosophy“ (maintain only last release) than NO TAGS.

@omansour

This comment has been minimized.

Show comment
Hide comment
@omansour

omansour Nov 4, 2013

I already experienced some BC problems. Those problems were blocking deployments - cause we cant deploy when CI is broken - very painfull story, so i am still not very confident with this solution.

but arguments heard, no problems, I can just fork the repo, tag it, put it on packagist or my own satis and live my life 🎱

omansour commented Nov 4, 2013

I already experienced some BC problems. Those problems were blocking deployments - cause we cant deploy when CI is broken - very painfull story, so i am still not very confident with this solution.

but arguments heard, no problems, I can just fork the repo, tag it, put it on packagist or my own satis and live my life 🎱

@jeremyFreeAgent

This comment has been minimized.

Show comment
Hide comment
@jeremyFreeAgent

jeremyFreeAgent Nov 4, 2013

Contributor

@omansour

I am a big fan, user and very small contributor to atoum but, as a manager off a large team depending on atoum to secure my deploiement, I will appreciate tagged versions.
I already experienced some BC problems. Those problems were blocking deployments - can we cant deploy when CI is broken - very painfull story, so i am still not very confident with this solution.

Same here.

@willdurand

Following semantic versioning helps your users know about new features, bug fixes and even BC breaks. So please consider using it or at least create some tags for those who care about version constraints.

👍

Contributor

jeremyFreeAgent commented Nov 4, 2013

@omansour

I am a big fan, user and very small contributor to atoum but, as a manager off a large team depending on atoum to secure my deploiement, I will appreciate tagged versions.
I already experienced some BC problems. Those problems were blocking deployments - can we cant deploy when CI is broken - very painfull story, so i am still not very confident with this solution.

Same here.

@willdurand

Following semantic versioning helps your users know about new features, bug fixes and even BC breaks. So please consider using it or at least create some tags for those who care about version constraints.

👍

@marmotz

This comment has been minimized.

Show comment
Hide comment
@marmotz

marmotz Nov 4, 2013

Contributor

@Ocramius Well.. actually, there is no problem. Just a demand from some users.
Atoum works well like that and i try to help when I explain (with a smiley !) that use "vx.y.z" or "dev-master" is same things in your composer.json.
Atoum use rolling release. Just like many linux distributions. It's like that, so use "dev-master". I update every day my desktop to have new packages, it's a life choice. If I want a versionned linux distribution, I'll use an other one.

I am not the lead dev of atoum, so i "can't" close this issue

Contributor

marmotz commented Nov 4, 2013

@Ocramius Well.. actually, there is no problem. Just a demand from some users.
Atoum works well like that and i try to help when I explain (with a smiley !) that use "vx.y.z" or "dev-master" is same things in your composer.json.
Atoum use rolling release. Just like many linux distributions. It's like that, so use "dev-master". I update every day my desktop to have new packages, it's a life choice. If I want a versionned linux distribution, I'll use an other one.

I am not the lead dev of atoum, so i "can't" close this issue

@Ocramius

This comment has been minimized.

Show comment
Hide comment
@Ocramius

Ocramius Nov 4, 2013

@marmotz never heard of an un-versioned distribution of linux. I'd feel like driving a car without brakes when running any update on a machine with such a software installed. That's experimental software that has no stability, and users accept that.

Users that need stability cannot rely on that, and by saying that autom doesn't have stability (master is not stable, whatever you say it isn't, it's a branch where stuff is pushed regularly) you simply drive users away from it or force companies to invest quite some money in driving away from it assuming they already adopted it.

The problem is real and it's here, as @omansour states a couple of comments above.

I suggest anyone involved in decision-making about the topic to re-read http://semver.org/ and finally make the decision to either close the thread or adopt that technique.

Ocramius commented Nov 4, 2013

@marmotz never heard of an un-versioned distribution of linux. I'd feel like driving a car without brakes when running any update on a machine with such a software installed. That's experimental software that has no stability, and users accept that.

Users that need stability cannot rely on that, and by saying that autom doesn't have stability (master is not stable, whatever you say it isn't, it's a branch where stuff is pushed regularly) you simply drive users away from it or force companies to invest quite some money in driving away from it assuming they already adopted it.

The problem is real and it's here, as @omansour states a couple of comments above.

I suggest anyone involved in decision-making about the topic to re-read http://semver.org/ and finally make the decision to either close the thread or adopt that technique.

@marmotz

This comment has been minimized.

Show comment
Hide comment
Contributor

marmotz commented Nov 4, 2013

@Ocramius

This comment has been minimized.

Show comment
Hide comment
@Ocramius

Ocramius Nov 4, 2013

@marmotz good to know - never ever heard of any of those as stable deployment systems :D

Ocramius commented Nov 4, 2013

@marmotz good to know - never ever heard of any of those as stable deployment systems :D

@marmotz

This comment has been minimized.

Show comment
Hide comment
@marmotz

marmotz Nov 4, 2013

Contributor

I use everyday Archlinux and I like it.

Contributor

marmotz commented Nov 4, 2013

I use everyday Archlinux and I like it.

@adrienbrault

This comment has been minimized.

Show comment
Hide comment
@adrienbrault

adrienbrault Nov 4, 2013

Regarding @Hywan's comment on "Rolling Releases" on #285

Linux distributions are totally different, they are binary releases (build step, people cannot really use the source repository directly), and distributions can update themselves. With php, it is the developer that triggers an update, and there is no build step. Additionally, Rolling releases in linux distributions to me looks like a feature for the user, not a choice from the maintainers to do less work.

Versioning in php does not mean people that people who want to use the package in a "Rolling Releases" way can't, they can still require dev-master or require 1.0.*@dev or 1.*@dev.
So if you want to keep the "Rolling Release" way for everyone, ask people to require 1.*@dev or *@dev dev-master in the readme, don't constrain everyone to install/update atoum the way you would do it.

The only downside of versioning is that you need to be aware when backward compatibility is broken, to know which version you need to tag. Additionally, to do that correctly you should maintain a CHANGELOG, and that is a really nice thing for users (I know, you maintainers don't care about that because you know everything, but please allow more people to easily follow atoum's features).

Nice try finding a good reason not to tag.

adrienbrault commented Nov 4, 2013

Regarding @Hywan's comment on "Rolling Releases" on #285

Linux distributions are totally different, they are binary releases (build step, people cannot really use the source repository directly), and distributions can update themselves. With php, it is the developer that triggers an update, and there is no build step. Additionally, Rolling releases in linux distributions to me looks like a feature for the user, not a choice from the maintainers to do less work.

Versioning in php does not mean people that people who want to use the package in a "Rolling Releases" way can't, they can still require dev-master or require 1.0.*@dev or 1.*@dev.
So if you want to keep the "Rolling Release" way for everyone, ask people to require 1.*@dev or *@dev dev-master in the readme, don't constrain everyone to install/update atoum the way you would do it.

The only downside of versioning is that you need to be aware when backward compatibility is broken, to know which version you need to tag. Additionally, to do that correctly you should maintain a CHANGELOG, and that is a really nice thing for users (I know, you maintainers don't care about that because you know everything, but please allow more people to easily follow atoum's features).

Nice try finding a good reason not to tag.

@marmotz

This comment has been minimized.

Show comment
Hide comment
@marmotz

marmotz Nov 4, 2013

Contributor

@adrienbrault Yes, you're right, it should be a feature and not an imposed things.

But @mageekguy has already explained his reasons for not tagging atoum. It's like that, atoum has adopted rolling-releases.

Contributor

marmotz commented Nov 4, 2013

@adrienbrault Yes, you're right, it should be a feature and not an imposed things.

But @mageekguy has already explained his reasons for not tagging atoum. It's like that, atoum has adopted rolling-releases.

@gauthier

This comment has been minimized.

Show comment
Hide comment
@gauthier

gauthier Nov 4, 2013

Contributor

@marmotz even those non-versioned GNU/Linux distros mostly contains versioned software :)

Two major issues with rolling release are:

  • documentation - which is never up-to-date with the current release
  • bc-breaks - several users already reported having encountered such issues (not for personal use by the way)

I dont think that such an important piece of software as a unit test framework is can ignore such troubles it causes to its users. Lack of versioning obviously prevent users from adopting atoum, because it's too risky... I think it's a shame because atoum is a very good and powerful unit test framework.

As long as there won't be any identified version, together with a complete documentation, it will be much harder for new-comers to get efficient with it than with PHPUnit. For instance, it's really hard to create a good training course for atoum, since it's moving too fast.

Anyway, as you said, it's up to @mageekguy to define the way he wants to drive atoum project...

Contributor

gauthier commented Nov 4, 2013

@marmotz even those non-versioned GNU/Linux distros mostly contains versioned software :)

Two major issues with rolling release are:

  • documentation - which is never up-to-date with the current release
  • bc-breaks - several users already reported having encountered such issues (not for personal use by the way)

I dont think that such an important piece of software as a unit test framework is can ignore such troubles it causes to its users. Lack of versioning obviously prevent users from adopting atoum, because it's too risky... I think it's a shame because atoum is a very good and powerful unit test framework.

As long as there won't be any identified version, together with a complete documentation, it will be much harder for new-comers to get efficient with it than with PHPUnit. For instance, it's really hard to create a good training course for atoum, since it's moving too fast.

Anyway, as you said, it's up to @mageekguy to define the way he wants to drive atoum project...

@mageekguy

This comment has been minimized.

Show comment
Hide comment
@mageekguy

mageekguy Nov 4, 2013

Contributor

Since it's moving too fast…
First time that i read that moving too fast is a drawback :D.

Contributor

mageekguy commented Nov 4, 2013

Since it's moving too fast…
First time that i read that moving too fast is a drawback :D.

@willdurand

This comment has been minimized.

Show comment
Hide comment
@willdurand

willdurand Nov 4, 2013

@mageekguy please close this issue. It will be your best argument.

willdurand commented Nov 4, 2013

@mageekguy please close this issue. It will be your best argument.

@bricecarpentier

This comment has been minimized.

Show comment
Hide comment
@bricecarpentier

bricecarpentier Nov 4, 2013

and then open it again, just for the sake of it

bricecarpentier commented Nov 4, 2013

and then open it again, just for the sake of it

@jubianchi

This comment has been minimized.

Show comment
Hide comment
@jubianchi

jubianchi Nov 5, 2013

Member

This issue will be closed in favor of a new one : #300

Member

jubianchi commented Nov 5, 2013

This issue will be closed in favor of a new one : #300

@jubianchi jubianchi closed this Nov 5, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment