Release Version To 'pub.dev'

[eliabieri]

There has been no release in 6 months. Any idea when a next version will be released?

[ibrierley]

Personally I don't have any idea, we've mainly been working on existing bug fixes recently. Any specific reason for wondering, and any specific things desired ? May be an interesting discussion to have.

[JaffaKetchup]

Currently, only the owner is able to publish to pub.dev, who hasn't been seen in a while.
Hopefully we can publish next time we see @johnpryan.

[jithware]

To avoid the bottleneck, it would be awesome if @johnpryan gave @JaffaKetchup and @ibrierley permission to release. See #1117 (reply in thread) for previous discussion.

[JaffaKetchup]

@johnpryan seems to be active elsewhere on GitHub, so hopefully he checks back here soon. I have the email address for him (from a GitHub commit), but I haven't contacted him on there yet.

[JaffaKetchup]

For anyone interested, some internal discussion has taken place on this/similar issue - but without @johnpryan's input.
Rest assured, we are still considering the best route forward, and we won't stop trying to get the owner's attention :)

[pablojimpas]

Is it possible to use the latest fixes & improvements of flutter_map using it directly from git alongside other plugins like flutter_map_marker_cluster that depend on a tagged hosted version of flutter_map?

[JaffaKetchup]

Not sure. But try this:

1. Change flutter_map import back to normal (flutter_map: )
2. Move what you had there to underneath dependency_overrides (not sure what it's called, check it)
3. Import other plugins normally.

If that doesn't work, you'll have to fork each plugin and change its pubspec.yaml, then include your version.

[pablojimpas]

Thanks @JaffaKetchup! I can confirm this approach works, no need to to fork each plugin. The obvious caveat is that compatibility it's not guaranteed, apparently there has been breaking changes in the plugins API recently. I had to change a bunch of Stream<Null> to Stream<void>.

[eliabieri]

Any progress in reaching out to @johnpryan ?

[JaffaKetchup]

Unfortunately not. I'll try to remember to send him an email tomorrow, but if that doesn't work, we'll have to figure out an alternative. Sorry for the delay!

[JaffaKetchup]

@eliabieri and others interested. Pinging @ibrierley as well here.
I've sent @johnpryan an email, so hopefully he responds.

[pablojimpas]

I've sent @johnpryan an email, so hopefully he responds.

I guess he may have been busy with the launch of Flutter 3 and Google I/O stuff. Maybe not the best timing 😆

[Solano-Furlan]

It looks like that this package in no longer maintained

[JaffaKetchup]

@Solano-Furlan Not to worry, there are still a few active maintainers!

[JaffaKetchup]

To all those interested:

@ibrierley and I have tried contacting @johnpryan multiple times through his multiple email addresses.
Unfortunately there has been no response in about a 2 week period. We are still hoping that he might return, but it's looking unlikely.
Internal discussions are taking place in a private Discord channel, and it's likely there will be more information soon. We can not provide much more info right now, as we think about potential routes forward.

Thank you for your ongoing support!

[pablojimpas]

I'll suggest NOT to split the package popularity by publishing a new one on pub.dev, we shall wait for the owner to release a new version and in the meantime we can tag releases using git/github so that plugins and users can rely on stable versions and move forward to get the new features if they want to.

[JaffaKetchup]

@pablojimpas Thanks for your input! Please join the discord if you haven't already, there will be a discussion there soon.

[JaffaKetchup]

@pablojimpas One thing to note about that approach is that dependencies from Git are strictly forbidden for packages uploaded on pub.dev (AFAIK). For example, a flutter_map plugin would still be locked to the pub.dev version, unless they also skip publishing and only allow installation from Git.

[ibrierley]

I don't think I like the idea of simply publishing a new one that diverges (yet) and doesn't offer something significantly different and splits things.

I was pondering if there was a way to lets say keep flutter_map normal Github as the main repo, and then having just a 2nd clone (eg called something like flutter_map_release) that mirrors the other and publishes to pub.dev on major updates though in the interim for anyone who needed it (I think pubspec may have to be updated every time, but I may be wrong). Not sure I like that idea either (yet) (or even if possible), still feels a bit messy and confusing for people.

It's interesting to hear ideas, and maybe feels a bit harsh to say it's not maintained when there's been quite a few fixes/merges/etc of late.

Still hoping none of it will be needed though :).

[pablojimpas]

@pablojimpas Thanks for your input! Please join the discord if you haven't already, there will be a discussion there soon.

I joined some time ago, but I don't check it very often.

@pablojimpas One thing to note about that approach is that dependencies from Git are strictly forbidden for packages uploaded on pub.dev (AFAIK). For example, a flutter_map plugin would still be locked to the pub.dev version, unless they also skip publishing and only allow installation from Git.

Of course, plugins are completely dependent on the main package, if the main package does not release new versions to pub.dev the plugins can't either. That way of releasing using git tags will be a completely parallel paradigm to stay up to date until it's possible to upload the new versions to pub.dev.

@ibrierley a mirror package used only for uploading newer versions could work...that will cause some confusion but it's reasonable, however if we can't upgrade the readme on the original flutter_map pub.dev page the community/users will be split anyways. Furthermore, another pub.dev package will be another single point of failure, since the new owner could disappear in any moment.

[ibrierley]

(ignore my pondering about a clone, it wouldn't really work).

[ibrierley]

I've just given John a gentle prod again.

Maybe one thing in the interim that would be useful to hear, is from those who need flutter_map updated in pub.dev.. (or if you couldn't use flutter_map because of it). Is it just other packages can't depend on the latest in Git ?

Wondering if something could be added to the docs if necessary.

One option r.e @pablojimpas point about a central point of failure with any new repo, if that was finally thought a good option.... I had taken a peek at fluttercommunity and one could transfer to them so they have future publish access i.e https://github.com/fluttercommunity/community & https://github.com/fluttercommunity/transfer-guide

[JaffaKetchup]

Yeah, it's pretty much only other packages that can't depend on Git. The publish command gives an error. Some people also consider it bad practise everywhere and should be avoided due to the risk of breaking changes.

New docs already mention installation from Git as an alternative to pub.dev. There's little point updating the READMEs because the pub.dev one (where most people look at installation instructions) would still be outdated.

I'm not sure about transferring to flutter_community? @johnpryan would need to transfer it anyway, and need to allow them to upload via his verified publisher: in which case he could just make us publishers. However, central point of failure is a good point. Is it possible in GitHub to have multiple owners, or at least multiple people with owner-similar permissions?

[ibrierley]

Doh, of course the readme wouldn't be updated on pub.dev ver :D.

For the Fluttercommunity thing, I meant as a separate package if it was thought best to go down that route eventually, just to avoid any central point of failure.

[JaffaKetchup]

Yeah, maybe like a backup fork that can be published if all maintainers disappear? Not sure if that's what you were thinking. You might then be able to use webhooks or Actions to auto-update the fork?

[ibrierley]

It was more, if we need to create a fork for whatever reason, @pablojimpas had just mentioned it was another single point of failure. I think fluttercommunity can be used (if they agree), so whoever was the new maintainer of the new package, could get fluttercommunity to take it over (example request here fluttercommunity/community#93 ) (bah didn't mean to create a referenced link in their issue!), the original maintainer carries on being able to publish (if wanted), but if they get hit by a truck, fluttercommunity can still publish, sort a new maintainer or whatever.

Don't want to get too hung up on the specifics of that though, hopefully it won't be needed, just mentioning it in case it's useful down the line.

[JaffaKetchup]

Ah I see. I guess that might be handy in the future!

[pablojimpas]

Some people also consider it bad practise everywhere and should be avoided due to the risk of breaking changes.

That's why I suggested using git tags to mark stable versions, but it will still be a half-baked solution since version constraints will be up to the user instead of being enforced by pub.

Transferring the package to flutter community will be a good option if that's the strategy long term, but I think we should get input from the owner before making such move.

I think the more realistic short-term solution will be setting up a custom package repository as an alternative to pub.dev: https://dart.dev/tools/pub/custom-package-repositories

[ibrierley]

Naturally I suspect if we can get input from John, the problem likely goes away anyway :D. Hopefully Johns ears will prick up at some point ! :). I don't see any need to rush with anything.

[JaffaKetchup]

Just pinging @johnpryan again.

[johnpryan]

1.0.0 has been published. Thanks for your patience 😅

[eliabieri]

I've created the following issues to bump the flutter_map dependency of the following packages to 1.0.0:
flutter_map_marker_cluster
flutter_map_location_marker -> PR
flutter_map_marker_popup

[JaffaKetchup]

@eliabieri Thanks, that's a great start :)

[pablojimpas]

I've created the following issues to bump the flutter_map dependency of the following packages to 1.0.0:
flutter_map_marker_cluster
flutter_map_location_marker -> PR
flutter_map_marker_popup

PR for flutter_map_marker_popup
PR for flutter_map_dragmarker
Draft PR for flutter_map_dragmarker

[jithware]

1.0.0 has been published. Thanks for your patience sweat_smile

@johnpryan to avoid delays in the future, can other contributors be given permission to publish (see #1117 (reply in thread))?

[ibrierley]

Hi @jithware that has already been done.

[jithware]

Thanks @ibrierley for the info! Great to know that publishing will be much more efficient now. I'm also interested in #1188 (comment). Hopefully the maintainers of the plugins will also update to the latest version.

[JaffaKetchup]

@jithware and others
You can follow updates more closely by joining the Discord server. For now, this is all sorted!