Replies: 4 comments 7 replies
-
|
@trusktr -- This is a good list. Thanks for putting it together and tackling much of the work. I think it's important to recognize that while this type of cleanup work will benefit maintainers, the end result of the items listed above do not provide a compelling reason for existing users to upgrade from v4. This isn't meant as a negative comment. I think Docsify needs this work to be done and that it will be in a much better place when this work is completed. My intention is only to point out that if we are going to introduce changes that will require a major version bump, we should also consider changes that directly benefit users so that they are incentivized to upgrade. One suggestion is update the UI visuals, HTML, and CSS for v5. If proposals for v5 include converting all of our CSS from Stylus to vanilla CSS and converting our HTML from string/templates to UI components then this would be an opportune time to do it. By incorporating lessons learned from docsify-themeable and popular component libraries we can offer an updated UI with flexible theming options. Since this change would be highly visible, I believe this change alone would motivate users to upgrade. A few quick thoughts regarding other items on the list above:
Ping: @sy-records, @Koooooo-7 |
Beta Was this translation helpful? Give feedback.
-
|
Moving to v6 immediately after releasing v5? |
Beta Was this translation helpful? Give feedback.
-
|
I think whether we could release v5 now or further we need have a agreement first.
|
Beta Was this translation helpful? Give feedback.
-
|
Yea, I agree with you mentioned @trusktr . we could do a general release based on version x.y.z rules --- If we have some remarkable breaking changes, we do the X release, otherwise, the Y or Z. then move on. If not, I think we need finish it asap and do the rest of things. |
Beta Was this translation helpful? Give feedback.
-
Yes, but this is just a proposal based on the idea that the work we'll focus on immediately after the release of v5 will likely include breaking changes and therefore require a major version bump. That idea came from my proposal to focus on docsify's UI and plugin system after v5 is released, but this is admittedly TBD. The in-progress triage of existing issues and PRs should help inform what comes after the release of v5. If we release v5 and determine we have non-breaking updates we want to focus on, then we'll focus on v5 minor and patch updates. If we choose to prioritize breaking changes, then yes, v6 is what we would focus on. If we want to focus on both, we can do that by isolating breaking changes on a separate branch and keeping that branch up to date with non-breaking changes as they are merged into the The macro point is that we want to release v5 sooner than later, then turn the corner to whatever comes next.
This is also TBD, but my preference would be for us to focus on the current and next versions only, limiting work on previous versions to critical bug fixes only as needed. |
Beta Was this translation helpful? Give feedback.
-
Yep, we don't have time, energy, resources to realistically want to maintain multiple versions (f.e. like Vue 2 and Vue 3). If someone needs continuous previous version support, please notify us and start a $1000 sponsorship plan (more or less depending on needs, let us know) here: https://github.com/sponsors/docsifyjs What we can afford right now is progressively enhancing Docsify over time, which might include breaks along the way, we'll make sure to clearly document the migration path, and we'll bump X/Y/Z accordingly. I mentioned it before, but Three.js's migration guide is a good example: https://github.com/mrdoob/three.js/wiki/Migration-Guide Almost every version of Three.js has a breaking change (which has not hindered it from being the most widely adopted 3D rendering library for web). The lib is big, so stable parts are very likely not to break, but parts of it that are stabilizing and progressing (especially new features, which often start in the examples folder instead of src folder) can break. For example, |
Beta Was this translation helpful? Give feedback.
-
|
I added a new one to the list above:
|
Beta Was this translation helpful? Give feedback.
-
|
Added a new bullet to the list above:
|
Beta Was this translation helpful? Give feedback.
-
|
I fantasize about removing the build. For example, we could just have a The less we have to maintain for a working product, the more we can advance features, and we can let others help us with code or sponsorship. Regarding the Vue stuff, I would really like to make that a standalone plugin rather than core feature. |
Beta Was this translation helpful? Give feedback.
-
We have some baggage,
.stylsyntax for our CSS. CSS has lots of new language features, including CSS Nesting which is out in all browsers (Firefox with a flagnow in Firefox without a flag), container queries, etc.I propose:
v5
(Any chained pull requests are in the same order as in this list)
.call, but rather be private methods. refactor: move some functions and module-level state into classes as private methods and properties to start to encapsulate Docsify #2136var->const, orfor(;;)->for(of), so it will be easier to review them sepatelyFuture release if not v5
Non breaking changes:
Potentially Breaking changes:
/index.htmlanddocs/index.html. Do we need duplicate code? Delete one.initGlobalAPI()along with the automaticnew Docsifyand instead require users to pass options intonew Docsify(options))using postcss for now only until CSS Nesting lands in FirefoxFirefox supports nesting now). These changes should be backwards compatible for docsify-themeable. Someone with a build system might consume these files, so major version bump.Beta Was this translation helpful? Give feedback.
All reactions