Skip to content

Migrate to 1.0.28 - Problem with CoreStoreSembastImp #478

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.

Sign up for GitHub

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

Jump to bottom
Closed
RodrigoSMarques opened this issue Oct 11, 2020 · 20 comments
Closed

Migrate to 1.0.28 - Problem with CoreStoreSembastImp #478

RodrigoSMarques opened this issue Oct 11, 2020 · 20 comments

Comments

@RodrigoSMarques
Copy link
Contributor

RodrigoSMarques commented Oct 11, 2020 •
edited
Loading

@phillwiggins and @fischerscode

I received the messages that the package had several changes, but I was unable to follow and perform tests.

I went to do a migration and found a BREAKING CHANGE problem using CoreStoreSembastImp and it is not documented.

Before in Version 1.0.27

class CoreStoreSembastImp implements CoreStore {
  CoreStoreSembastImp._internal(this._database, this._store);

  static CoreStoreSembastImp _instance;

  static Future<CoreStore> getInstance(
      {DatabaseFactory factory, String password = 'flutter_sdk'}) async {

After in Version 1.0.28

class CoreStoreSembastImp implements CoreStore {
  CoreStoreSembastImp._internal(this._database, this._store);

  static CoreStoreSembastImp _instance;

  static Future<CoreStore> getInstance(String dbPath,
      {DatabaseFactory factory, String password = 'flutter_sdk'}) async {

What dbPath parameter is this? Can't it have a default value?

Another question. Who uses the package with Flutter and does not migrate to the new package, what problems will they have?

If we have other BREAKING CHANGES, the package version should be 2.0.0 to indicate that there is incompatibility (Semantic Versioning https://semver.org/spec/v2.0.0-rc.1.html)

If the goal of separating a pure dart package was to be compatible with Flutter Web, this was not necessary.

Search for Federative Plugins
https://flutter.dev/docs/development/packages-and-plugins/developing-packages#federated-plugins
@fischerscode
Copy link
Contributor

I assume you have just replaced

parse_server_sdk: ^1.0.27

with

parse_server_sdk: ^1.0.28

inside of you pubspec.yaml.

What dbPath parameter is this? Can't it have a default value?

As path_provider can't be used in dart projects, we have to provide the database path using a string.

Another question. Who uses the package with Flutter and does not migrate to the new package, what problems will they have?

Everybody who uses the 1.0.27 (with flutter) should migrate to parse_server_sdk_flutter 1.0.28 and when using the migration guide, everything should work.
All Flutter related packages have been removed in order to support dart projects. As a result, all auto-discovery features used in the package must now be implicitly set. As a result, using the non flutter package is not developer friendly.

If we have other BREAKING CHANGES, the package version should be 2.0.0 to indicate that there is incompatibility (Semantic Versioning https://semver.org/spec/v2.0.0-rc.1.html)

In the README of version 1.0.27 it says:

This is a work in progress and we are consistently updating it.
As this is an early development with multiple contributors, it is probably best to download/clone and keep updating as an when a new feature is added.

But, sure a different version number might have been not to bad, but considering the version has been 1.0.27 (Major: 1, Minor: 0 (!), Patch: 27), going to 2.0.0 would have been a far to large jump.

If the goal of separating a pure dart package was to be compatible with Flutter Web, this was not necessary.

Flutter Web was already almost supported with 1.0.27. The goal of separating a pure dart package was to be able to use the package in a pure dart project. (server application, console application, ...)

@RodrigoSMarques
Copy link
Contributor Author

I understood the issue, my project is working.
For me it was simple, I was following Git messages.
This was just an exercise.

As there was only an increment in the patch version, I am sure that many will not notice that the package has changed.

The changelog says that the package has been separated, but for example, it does not advise that anyone who uses Flutter should change the package and do the migration.

I know there is guidance on the page, but it is not highlighted.

I work daily with developers with all levels of knowledge.

I have a Flutter course on an online platform with more than 30,000 students. There we built an app using Parse Server and the package.

It may seem simple, but I am sure that many will have difficulties in migrating.

Not because the migration process is complicated, but because in version 1.0.28, you expect a patch and not a change in your working code.

If there was a split between Dart and Flutter, jumping to version 2.0.0 is not wrong.

In doing this, you are saying: "I have a big change, you need to check the changelog and check some migration guide".

See for example the provider's package:
https://pub.dev/packages/provider#migration-from-v3x0-to-v400

oK, now it's clear why having a pure dart code.

Well, this is my point of view.

@fischerscode
Copy link
Contributor

fischerscode commented Oct 12, 2020 •
edited
Loading

Well, this is my point of view.

I see you point and the problem you are pointing out.

I think the version numbers of this project are unconventional, as the version number of the next release is already set just a second after the previous release, due to the work being done in a separated branch and not the master branch.
During development of 1.0.28 @phillwiggins wrote:

I'm happy to have a develop branch, create release branches from
that when ready and merge back to master when released.

So maybe we should start doing it like this while working on the next releases.

I see three options now:

  1. leave 1.0.28 as it is and publish a new version (with some version number, maybe 2.0.0) with additional information how to migrate
  2. remove 1.0.28 from parse_server_sdk. And do point 1
  3. leave everything as it is and release 1.0.28+1 with an additional note about the importance of migrating.

But as the pub.dev sites are owned by @phillwiggins, it's his decision.

@RodrigoSMarques
What would you suggest?

@phillwiggins

I'm happy to have a develop branch, create release branches from that when ready and merge back to master when released.

Are you fine with developing the next release like that?

@phillwiggins
Copy link
Member

phillwiggins commented Oct 12, 2020 via email

@fischerscode
Copy link
Contributor

@phillwiggins
Great 👍

And what do you think is the best option / what option would you like to choose?

  1. leave 1.0.28 as it is and publish a new version (with some version number, maybe 2.0.0) with additional information how to migrate
  2. remove 1.0.28 from parse_server_sdk. And do point 1
  3. leave everything as it is and release 1.0.28+1 with an additional note about the importance of migrating.

@phillwiggins
Copy link
Member

phillwiggins commented Oct 12, 2020 via email

@fischerscode
Copy link
Contributor

@phillwiggins
I agree that the versioning is far from optimal. I think I would even suggest option 2.
For the future, I would suggest releasing more often. Something like #448 would be a nice patch.
As I am starting to use this package in production, I would volunteer to keep track of changes and try to bundle them in versions.

@phillwiggins
Copy link
Member

phillwiggins commented Oct 12, 2020 via email

@fischerscode
Copy link
Contributor

@phillwiggins
Ok, and should we request the removal of parse_server_sdk 1.0.28? (I think you would have to do this, as it would be a security flaw, if I would be able to do this.)
I will create 2.0.0 in something like an hour. And @mention you if it is done.

@phillwiggins
Copy link
Member

phillwiggins commented Oct 12, 2020 via email

@RodrigoSMarques
Copy link
Contributor Author

A suggestion of the way I work on my package and also on my "normal" work, on the day.

I have a fix branch and one of new features / improvements.

When a correction is made, it can be published and then merged with the master and improvements branch.

The reverse follows the same flow.

This allows fixes to be released soon, without waiting for a big package along with improvements.

Versions are not named in the Branch, only in the release tag.

We can create a Wiki with guidelines on how pull requests should be carried out.

@fischerscode fischerscode mentioned this issue Oct 12, 2020
Merged
@fischerscode
Copy link
Contributor

@RodrigoSMarques
Sounds good.

@phillwiggins
Copy link
Member

phillwiggins commented Oct 12, 2020 via email

@fischerscode
Copy link
Contributor

I think pub.dev actually points to master.

I thought pub publish uploads the current snapshot of the directory to pub.dev.

I would create a Dev branch of some sort and merge features branches into Dev. Only merge Dev into master
upon release.

But wouldn't cherry picking important bug-fixes into master still an option?

@fischerscode
Copy link
Contributor

@phillwiggins
Thanks for publishing 2.0.0.
Are you going to request the removal of parse_server_sdk 1.0.28, or is it better to leave it?

@phillwiggins
Copy link
Member

phillwiggins commented Oct 13, 2020 via email

@fischerscode
Copy link
Contributor

@phillwiggins
This comment says, it is possible by contacting them.

@phillwiggins
Copy link
Member

phillwiggins commented Oct 13, 2020 via email

@fischerscode
Copy link
Contributor

I would create a Dev branch ofsome sort and merge features branches into Dev.

I've created a development branch.

@RodrigoSMarques
Copy link
Contributor Author

Fix in Version 2.0.0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@phillwiggins @RodrigoSMarques @fischerscode