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.

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

Checklist for PouchDB 7.0.0 #6356

Closed
nolanlawson opened this Issue Mar 20, 2017 · 11 comments

Comments

Projects
None yet
6 participants
@nolanlawson
Copy link
Member

nolanlawson commented Mar 20, 2017

Summary

We released 6.0.0 in September 2016, and 5.0.0 in December 2015. I agree with Tom Dale that SemVer shouldn't mean more breaking changes, so to keep us around ~1 major release per year, I'd propose a 7.0.0 release later this year.

I think the ideal strategy is to cram as many breaking changes as possible into a few infrequent releases. You don't want users to have to wonder: "Hmmm, in v7 they removed this, and in v8 they removed that, and in v9 they removed another thing, so if I'm on v5 and want to upgrade to v10...". Keep it simple.

Following up on discussion in #6019, this is a living list of breaking changes for PouchDB 7.0.0. Please comment here if anything concerns you, or if there are other changes you'd like to add.

TODOs

  • extract PouchDB.debug() as its own plugin (saves ~2KB) (#6158)
  • extract pouchdb-mapreduce from pouchdb-core (saves ~4.5KB)
  • remove db.type() (#6346)
  • map filters require strict mode (#6247)

Nice-to-haves, may not make it

  • extract polyfills (doesn't seem worth it yet: #6019 (comment))
  • deterministic revs by default (I'm worried about perf overhead, docs complexity) (#4642)
  • extract replication/changes filters as their own plugin (#6355)
  • remove/rename PouchDB.preferredAdapters, PouchDB.prefix, PouchDB.adapters (high breakage risk, low benefit)
  • db object should not be a promise for itself – causes "circular promise" errors, unnecessary now that the constructor is stateless (new)
  • extract PouchDB.defaults() as its own plugin (saves little, but hard to maintain) (moved to "nice to have," seems this may be tricky)

Planning

In terms of strategy, I think we should create a separate branch called breaking and keep it rebased against master. That way, we don't need to worry about merging breaking changes into master, or feel tempted to do a major release prematurely.

My hunch is that 7.0.0 will be the last major release before idb-next lands in 8.0.0. I think IDB in Safari is still not widespread enough to start focusing on it yet (10.1 isn't even officially released yet, there are bugs: #6349), and we need to work on perf of idb-next and IE/Edge compatibility (I'm happy to take responsibility for that; it may take the form of a separate plugin like idb-iegap).

We should probably also use dist-tags to start shipping alpha versions of 7.0.0 to npm before it's officially released. Babel, Webpack, and many other projects have had success with this strategy.

@garrensmith

This comment has been minimized.

Copy link
Member

garrensmith commented Mar 24, 2017

The other thing I would like for 7.0 is to take pouchdb-find out of beta. I think pouchdb-find is reaching a pretty stable state and I'm happy to do some work over the next few weeks to close out the final list of bugs.

@nolanlawson

This comment has been minimized.

Copy link
Member

nolanlawson commented Mar 24, 2017

Yup, I agree. No reason to call it "beta" anymore. The actual indexing is 100% solid because it's based on pouchdb-abstract-mapreduce. The only thing that's still incomplete is the query language, but that's less of a big deal because it can always be fixed later, without requiring data migration.

In fact since we publish all packages at the same version, looks like pouchdb-find will jump from 0.10.5 to 5.x which definitely communicates "not in beta anymore." 😊

@lifaon74

This comment has been minimized.

Copy link

lifaon74 commented Mar 27, 2017

About polyfill, I think it could be great to remove them from core for 2 reasons :

  1. Some user maybe target only last browsers/nodejs expecting a minimum size
  2. Most of the time, front end developpers (in browser) use core-js or their own polyfills, so it could result in unecessary code redondancy.

By the way, guys you do a great job, thanks to you.

@nolanlawson

This comment has been minimized.

Copy link
Member

nolanlawson commented Mar 31, 2017

Most of the time, front end developpers (in browser) use core-js or their own polyfills

I'm not sure this is actually the case. I don't have data, but my hunch is that since Webpack/Browserify are new technologies, most webdevs are still using old-fashioned <script> tags or something similar.

I think it's important to strike a balance between "works out of the box" for beginners and "I can customize to my liking" for experts. Take a look at #6377 where I'm trying to make this a bit more explicit without needing to yank out features for absolutely everybody. 😃

@lifaon74

This comment has been minimized.

Copy link

lifaon74 commented Apr 1, 2017

I aggree on the fact that beginners will use <script> tag. But for professional, it's mandatory use use bundler (like rollup => strong compression and one output file), minimifier, tests, automation (ex: gulp), etc... All peoples dont live in european or north american countries. India or China represent a big market (billions of people) and still have a slow connection... Same for mobile devices...

For a "works out of the box" you could provide some king of "pouchdb-web-full.js" which could import pouchdb-core, pouchdb-mapreduce, shims, etc...

@nolanlawson

This comment has been minimized.

Copy link
Member

nolanlawson commented Apr 1, 2017

@lifaon74 Does the proposed pouchdb-lite work well for you? Typically I prefer for the default to be "works out of the box", since beginners often don't read very deeply in the documentation before they start to use it. Your points are valid, but if newbies can't quickly get up-and-running with an open-source project they will just use another one.

@ntodd

This comment has been minimized.

Copy link

ntodd commented Aug 9, 2017

I think IDB in Safari is still not widespread enough to start focusing on it yet (10.1 isn't even officially released yet, there are bugs: #6349)

@nolanlawson Since iOS is now at 10.3 (almost 11.0) and #6349 is closed, is there anything still holding up IDB support in later versions of Safari?

@daleharvey

This comment has been minimized.

Copy link
Member

daleharvey commented Aug 9, 2017

I think the current blocker is saucelabs supporting a late enough version of safari, I think last time I checked they still only support 10.1, we cant release anything big like that unless it is tested in automation

@stale

This comment has been minimized.

Copy link

stale bot commented Nov 29, 2017

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added wontfix and removed wontfix labels Nov 29, 2017

@nename0 nename0 added the pinned label Dec 1, 2017

@daleharvey daleharvey referenced this issue Dec 17, 2017

Closed

PouchDB 7.0 #6946

8 of 8 tasks complete
@daleharvey

This comment has been minimized.

Copy link
Member

daleharvey commented Dec 17, 2017

Opened a new issue for this as almost a year gone by and the issue priority is different now

@daleharvey daleharvey closed this Dec 17, 2017

@daleharvey

This comment has been minimized.

Copy link
Member

daleharvey commented Dec 17, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment