Api: Support 2.0.0 final to prevent minimum-stability: dev on production

[GabrielGil]

| Q | A
| ----------------- | ---
| Bug? | no
| New Feature? | no
| Framework | Laravel
| Framework version | 5.6
| Package version | 2.0.0-alpha2
| PHP version | 5.x.y|7.x.y

Actual Behaviour

It's been a little bit over three years since the last "non-dev" version. This forces my team to have "minimum-stability": "dev" in my composer.json since this is the only package with the "@dev" suffix.

Expected Behaviour

Is there any plan to release v2 at some point, or it is going to happen like with version 1? I think it is time to release 2.0 finally, and add new releases with the bugfixes, since that is the version most users are using and most of the documentation does not reflect anymore versions 0.10.X.

Also, the current stable version 0.10.0 is not compatible with the supported versions of Laravel.

Steps to Reproduce

N/A

Possible Solutions

Release 2.0.0 version stable.

[specialtactics]

I think it's not ready for conservative "prod stability", however there's nothing preventing you from using this package in production - that's what I do.

Probably once all the issues are cleaned out and we address any outstanding ones, then it can be released?

[GabrielGil]

Thank you for your reply.

I understand your statement. What is exactly what is missing in order to be prod-ready? Is there a milestone updated? If so, is there an estimation of contributions needed to achieve this stage?

It has been quite a number of years already without a pro-ready version, maybe there's something I could contribute to help also. Cheers.

[specialtactics]

I think we just need a good overview of the issues remaining, if there aren't any then let's tag 2.0.0 :+1:

[GabrielGil]

I agree. Please, let me know how I or my team can contribute. I would be happy to contribute. Not sure if you use a Gitter chat or something else.

[eppak]

@specialtactics I have a question, maybe is lack of knowlegde in composer but: you say "however there's nothing preventing you from using this package in production - that's what I do". I want to do the same, but how to deal with the other packages, once you change the minumum stability with an update all packages change to dev. I trust dingo, but i can trust others? 😉

If you have suggestion i'll be glad to have a solution for this situation.
Thank you

[specialtactics]

@eppak That sounds like it would be a problem if you are using the dev-master reference of many projects - not just dingo. This should be the exception rather than the norm, and even then you can still specify specific commits.

That latter strategy is what I use, whenever I want to use a non tagged version of a package, I will specify the specific commit (which usually fixes or adds something pivotal), and make a note to go back to using the tag once it's tagged next, and check them every month or so.

Dingo is actually the only 3rd party package I use a master dev version of, and mostly because the package at the moment is being developed slower than would be ideal, but also because I am extremely familiar with it to the point of knowing every PR that goes into it - so if I ever need to pause and put it on a certain commit, I can do it immediately.

Actually at the moment I am using my own fork of the project because I have several PRs pending also.

[eppak]

@specialtactics It is exactly my case, i want to add to a more complex application rather than alone. I think that the "solution" can be a fork.

If can be safe to use it in production i think it can be switched, but you know it better than me.
Thank you for the response.

[specialtactics]

@eppak I think it's fine to use the current commit hash on master in production, and then just check back to see if it's been tagged.

[GabrielGil]

Thank you for all the different solutions here proposed but, I can't avoid one more question then. If everyone agrees on the fact of master being of enough trust and safe enough to use in production, why is not tagged directly as version two?

«Bugfree» software does not exist, and if in 2.0.0 an issue is found, that's what 2.0.1 is meant for. What are your thoughts guys?

[eppak]

@GabrielGil I agree with this statement but i think is the a lead decision, what i can ask @specialtactics is to add the proposition of point directly to the commit as a workarond on documentation.

[GabrielGil]

Completely agreed; it is a lead decision. Let's see what their thoughts are and if this makes sense for 'em too.

[GabrielGil]

Hey guys. It is going to be a year soon since 2.0.0 alpha two was released. Any update on this decision to make a stable release?
https://github.com/dingo/api/releases/tag/v2.0.0-alpha2

[specialtactics]

Hey guys

Good news, as Jason has added me to the project team.

I've just merged a ton of PRs and tagged master as v2.0.0-beta1

Although still a "pre-release", there's no issue with using this in production in my view (and I am doing the same).

I want to address a bunch more recent issues and finish off any PRs which need only minor changes before tagging as 2.0.0 final. I'll be away until start of Feb though, so I will aim to finish this by end of Feb.

[chriskonnertz]

@specialtactics

I will aim to finish this by end of Feb

Hey, is this still the current schedule?

[specialtactics]

@specialtactics

I will aim to finish this by end of Feb

Hey, is this still the current schedule?

@chriskonnertz Yes, I will try and prioritise issues/PRs which I think are a blocker, but just from what I have seen so far, I don't think there is anything major (ie. that can't be resolved after 2.0.0 release). To that end, I might actually do it sooner.

[chriskonnertz]

Thank you, I am very glad to hear that!

[specialtactics]

v2 tagged, closing this issue.

[chriskonnertz]

Awesome! :)