2.0 Roadmap

[leon0399]

Let's discuss ideas regarding new features, that require breaking changes here

[leon0399]

Everything, that can be done (except maybe documentation updates), without breaking changes, is done. Package didn't got properly maintained and refactored with new features in mind of a lot of years.

But we should not forget about maintaining current version (version 1..) supported, to provide smooth transition for users of original package

So I propose, that now on we may stop adding new features into 1.. versions, and focus only on supporting it (fix bugs, update documentation, etc.), but all the new issues we shall plan for the new version (let's call it 2.0)

Also, I personally do not like how a lot of packages trying to create less major releases, I see nothing wrong releasing several major releases per yer (e.g. one after new minor PHP version release, one more after new major Laravel version, one more after new underlaying library release, etc.). This makes breaking changes more granular, and easier for users to transit by one step at the time, instead of a bunch of breking changes

[leon0399]

Thing I see needs to be changes/removed on 2.0

• Remove namshi/jose, since it's deprecated by the author
• May be add web-token/jwt-framework as a alternative for JWT library, as it seems to have more supported features (lcobucci/jwt does not support PS256, PS384, PS512 and ES256K)

[mfn]

No me, someone else brought this up:

• remove support for PHP 7.4
  • which can mean using tools like rector to auto-upgrade everything to latest
    which likely brings more breaking changes

But we should not forget about maintaining current version (version 1..) supported, to provide smooth transition for users of original package

👍🏼

I still don't know how this will work with the main and develop branch strategy. I still, right now, find it confusing and TBH: unnecessary. Because main essentially IS develop because develop gets semi-periodically merged into main but main never receives PR directly or other merges/commits.

Why am I bringing this up again: such a model would suggest the same would/should/could be done for a 1.x branch maintenance which… IDK, feels wrong and "bloated".

I still believe this branching model should be simplier:

• get rid if develop and just have main, serving as the branch we make releases from

If we agree to have 1.x maintained (because for original fork backwards compat and smooth transition), we should ASAP branch this then from main.

So a possible scenario cold look like:

• main branch; PRs directly go in there
• 1.x branch cut at some point soonish from main

I think having a well maintained changelog can remove the "second branch" necessity easily.

I see nothing wrong releasing several major releases per year

I agree, I think considering https://semver.org/ or being close to it would benefit and make every ones (maintainers and users of this library) easier; to quote:

Summary
Given a version number MAJOR.MINOR.PATCH, increment the:

• MAJOR version when you make incompatible API changes,
• MINOR version when you add functionality in a backwards compatible manner, and
• PATCH version when you make backwards compatible bug fixes.

There are even tools there helping detecting breaking changes (though I never used them, so can't speak for their quality). Quick search results: https://github.com/tomzx/php-semver-checker and https://github.com/jbuncle/php-autosemver

[leon0399]

Agree, we should use different branching model, that git-flow

• main branch; PRs directly go in there
• 1.x branch cut at some point soonish from main

Very supportive to this 👍

agree, I think considering https://semver.org/ or being close to it would benefit and make every ones

Already added this into CHANGELOG, and thought of adding this to contributing guide

[mfn]

Already added this into CHANGELOG

…

and this project adheres to Semantic Versioning.

lol, indeed missed this. Well, I think a lot of things are falling naturally in place here 😄

[mfn]

As per #72 (comment)

• Octane compatability

😏

[mfn]

I've just added a PR to start getting phpstan into the project #79

My vision here is, and this would be items for the roadmap due to likely changes being required:

• Further embrace phpstan
  • resolve phpstan baseline as good as possible
  • bump the levels as high as possible
• Add https://github.com/thecodingmachine/safe/ to the project
  (which includes phpstan support!)

[leon0399]

I've added 2.0 milestone

[mfn]

We currently have no open PRs but some issues with "enhancement", some of them linked already here.

Is this maybe the signal to cut ties with the 1.x branch and move forward with 2.x + all the breaking changes we want to make + have a proper upgrade guide for this maintained along (or: in the changelog).

I'm referring to #76 (reply in thread)

[mfn]

I found out about https://github.com/PHP-Open-Source-Saver/jwt-auth/projects/1 today when I browsed #30

I would rather discuss this first before deciding to go with Projects.

TBH, IMHO they are not (yet?) a good fit and there's not much purpose having a "triaged", "high priority" etc. on project 100% consisting of volunteers. Why do what we want to do when we think it's fun. There's no project manager next to use making these decisions for what we should work on.

TL;DR: for consistency and less complexity, I highly suggest to stick with milestones https://github.com/PHP-Open-Source-Saver/jwt-auth/milestones for now.

[leon0399]

We also should determine, what to do with existing 2.0 branch.

[eschricker]

@Messhias your PR #105 is targetting the 2.0 branch. But this is the old one from tymon. Shouldn't we drop this branch and create a new branch containing the changes for 2.0?

[leon0399]

I can suggest not to drop old one, rather rename it to something like 2.0-old

[Messhias]

@Messhias your PR #105 is targetting the 2.0 branch. But this is the old one from tymon. Shouldn't we drop this branch and create a new branch containing the changes for 2.0?

Yes let's do that and keep 2 separated versions, 1.x to <8.0 and 2.x to >8.1. Whatever you guys want to start let me know and I'll close the PR and open it again in the new target branch.

[Messhias]

Yes, it could be, but it seems this 2.0 I'll be left behind since Tymon created it didn't forward with it. If you took a look at branch 2.0 (old one) our 1. x seems more advanced and updated in a lot of terms.

[mfn]

I looked at https://github.com/PHP-Open-Source-Saver/jwt-auth/branches/all and deleted a few branches were the PRs were merged.

Again I took a look at the 2.0 branch and easily come to the same conclusion as I already wrote in #76 (reply in thread)

• the diverges is too big to be merged
• inspiration can be take for some changes (like: all-in property types, etc.)
• as I said, I think the actual value is minimal; I think we can remove our 2.0 in an instant and not much is lost and we still have https://github.com/tymondesigns/jwt-auth/tree/2.0 if someone really wants to look at it.

TL;DR: I think the 2.0 we inherited is a waste of time keeping/talking much about it and it can be removed.

---

As for moving forward, some thoughts of mine:

• main should receive PHP 8+ BC compatible fixes so ppl don't get annoyed with deprecation warnings, i.e. what I suggested in Hotfix/fix php 8.1 warnings #105 (review)
• I'm not necessarily sold on the "mythical roadmap" which hordes commit over an undetermined timespan and then a big bang release
• there's nothing wrong with pumping out major versions whenever something breaks IMHO
• e.g. what is mentioned in Octane compatability #72 (comment) can be major version without having to drop currently supported PHP version, i.e. technically we can fix the Octane incompatibilities on main and create a 2.0 just for that
  I bet the breaking changes won't affect most ppl and no need yet to kick out PHP 7.4 users yet

[leon0399]

Okay, let's start listing features, that might be a part of 2.0

I'll start 😄

• Users, from JWT only, without database (JWT without users database #80)
• Separate refresh tokens (Separate refresh_token #71)
• Provide auth routes by package
• Remove namshi/jose as it is deprecated

Also, let's don't forget, that we are not wanna become second Passport, our purpose, IMO, is to provide something simpler. But we might peep into some of it's features

[alignwebs]

Hey @leon0399 any update over this ?

[Messhias]

Hey @leon0399 any update over this?

he's away for while because of the war in ukraine.

[specialtactics]

I broadly agree.

I suggest once v2 is ready, branch off master into a v1 branch to continue to maintain the v1 release that way for some period of time, and meanwhile master will become v2. I think it's a good idea to require PHP 8 from v2 onwards, and drop support for PHP 7.4 in that release line.