Migrate to 1.0.28 - Problem with CoreStoreSembastImp

[RodrigoSMarques]

@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]

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]

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]

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]

Yep, that works for me. It's mostly the practice I have been using professionally and I would imagine is probably the most popular behaviour?

…

On Mon, 12 Oct 2020, 10:33 Maximilian Fischer, ***@***.***> wrote: 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 <https://github.com/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 <#460 (comment)> a new version (with some version number, maybe 2.0.0) with additional information how to migrate 2. remove 1.0.28 <dart-lang/pub-dev#2099 (comment)> from parse_server_sdk. And do point 1 3. leave everything as it is and release 1.0.28+1 <#460 (comment)> with an additional note about the importance of migrating. But as the pub.dev sites are owned by @phillwiggins <https://github.com/phillwiggins>, it's his decision. @RodrigoSMarques <https://github.com/RodrigoSMarques> What would you suggest? @phillwiggins <https://github.com/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? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#478 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB4CPXQHMUA5HOV6F33E533SKLEPZANCNFSM4SMDPWBA> .

[fischerscode]

@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]

I agree that we had overlooked the version codes. As this is a major change we should probably label this as 2.x.x. What's everyone else's thoughts?

…

On Mon, 12 Oct 2020, 11:14 Maximilian Fischer, ***@***.***> wrote: @phillwiggins <https://github.com/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 <#460 (comment)> a new version (with some version number, maybe 2.0.0) with additional information how to migrate 2. remove 1.0.28 <dart-lang/pub-dev#2099 (comment)> from parse_server_sdk. And do point 1 3. leave everything as it is and release 1.0.28+1 <#460 (comment)> with an additional note about the importance of migrating. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#478 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB4CPXV77BJYQAULM33N3HTSKLJKHANCNFSM4SMDPWBA> .

[fischerscode]

@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]

Yeah, that's fine with me. If you're free and want to create the 2.0.0 (or whatever we choose) release, I'm more than happy to publish it?

…

On Mon, 12 Oct 2020, 11:24 Maximilian Fischer, ***@***.***> wrote: @phillwiggins <https://github.com/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 <#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. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#478 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB4CPXX7E4LDDWPWLBYXVOLSKLKPJANCNFSM4SMDPWBA> .

[fischerscode]

@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]

Okay cool. Thank you!

…

On Mon, 12 Oct 2020, 12:01 Maximilian Fischer, ***@***.***> wrote: @phillwiggins <https://github.com/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. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#478 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB4CPXUOMODV6OG2DKRD6LTSKLOZ3ANCNFSM4SMDPWBA> .

[RodrigoSMarques]

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]

@RodrigoSMarques
Sounds good.

[phillwiggins]

I think pub.dev actually points to master. I would create a Dev branch of some sort and merge features branches into Dev. Only merge Dev into master upon release.

…

On Mon, 12 Oct 2020, 13:54 Maximilian Fischer, ***@***.***> wrote: @RodrigoSMarques <https://github.com/RodrigoSMarques> Sounds good. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#478 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB4CPXWLFYFSBW4TAWPXBBDSKL4CHANCNFSM4SMDPWBA> .

[fischerscode]

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?