Easy_localization: Suggestions for better package maintenence

[spiritinlife]

Hello to all contributors and thank you @aissat for your work here.

Since flutter is gaining traction and this package is one of the best, most feature rich, json localisation libraries at the moment, I think we need to take a moment and organise how this library should proceed and i would like to have an open discussion about this.

My suggestions/initial thoughts are:

• [x] Create a dev branch where all development is done. Master branch should be the latest release.
• [X] Add pub.dev badge
• [x] Continue work on unit testing and start widget testing
• [x] Add code coverage information and badges?
• [X] Add ci for testing before merges

[aissat]

nice @spiritinlife :+1:

[spiritinlife]

@aissat nice i see u have started working on 5 🚀 .

Can you also check 3, in the unit tests i have done i have left some functions with @TODO where i am not sure how to proceed.

[danilofuchs]

I also think this project should better respect semantic versioning.
From 1.3.5 to 1.4.0 (link), there was a major breaking change, which made us refactor a lot of our production code. It should have been a major version bump (from 1.3.5 to 2.0.0).

Before making changes like that, I would really like the maintainers to discuss via issues what feature to add / remove before any releases or commits on master branch. On a side note, I personally would be against the change, given that AppLocalizations.of(context).tr is pretty straightforward and not as "magical" as a global tr method or string extension

[danilofuchs]

Overall, I think this project has great potential, and can in the future become one of the main ways for translating flutter apps. And for that, a great API and stability is essential

[aissat]

I also think this project should better respect semantic versioning.
From 1.3.5 to 1.4.0 (link), there was a major breaking change, which made us refactor a lot of our production code. It should have been a major version bump (from 1.3.5 to 2.0.0).

Before making changes like that, I would really like the maintainers to discuss via issues what feature to add / remove before any releases or commits on master branch. On a side note, I personally would be against the change, given that AppLocalizations.of(context).tr is pretty straightforward and not as "magical" as a global tr method or string extension

@danilofuchs I agree with u about

It should have been a major version bump (from 1.3.5 to 2.0.0).

are u against used global tr method or string extension

I personally would be against the change, given that AppLocalizations.of(context).tr is pretty straightforward and not as "magical" as a global tr method or string extension

[danilofuchs]

It should have been a major version bump (from 1.3.5 to 2.0.0).

are u against used global tr method or string extension

More than being against or in favour of this specific change, I think these changes should be debated via an issue, so all the community can express their opinions

[aissat]

@danilofuchs respect your point ageer with u

[danilofuchs]

I would like to add another point to this list:

• Squashing PRs when merging into development branch.

This is a great way to reduce clutter in git history and vastly simplifies rebasing a develop branch.

WARNING: We should never squash develop -> master, as develop will instantly be out of date with master and will need to be hard reset to fix it. I don't know a way to disable this option in Github UI.

I work daily applying this pattern and it is great! I haven't seen any complaint from anyone, including senior devs. The only downside is remembering to not squash develop.