Editor Team - First Release Coordination 🙌🎉

[emilyashley]

Happy Monday! Looks like everyone is hard at work -- I’m interested to see what pulling together some of our changes looks like for pushing out our first release together as team 🎉

Curious what the release process looks like? Me, too — I’m also new to this project. Here's a mostly blank issue for us to sort out our thoughts and gather existing documentation. We can update this description as we go!

Let’s start by:

1. Identify one thing you’ve done or solved that you’d like to see in our first release and

2. the steps we’d take to get it represented in a new release of the editor (or corresponding) repository.

And then we can work thru the second part together and coordinate a release with work from each team member!

(And maybe after even gather notes on how to improve the process for our second release? Think of this first one as a simplified dress rehearsal with one item from each member to iron out the process, our next release will probably be slightly bigger and more complex 🙌)

---

Issues to Track for Release 1 📋

• Popup Disappearing problem (Popup Disappearing problem solved jywarren/woofmark#3)
• Drag and drop CSS (Refine drag and drop events to prevent interference with other drag/drop-sensitive fields in downstream use cases jywarren/woofmark#2)
• Choose File button UI improvement Choose File button UI improvement #462
• Remove file button added Remove file button added #472
• Fixed toolbar fix toolbar stickness issue  #522
• Bug report button and template Add user workflow for documenting bugs #530
• Feature to change heading back into plain text (Feature to change heading back into plain text jywarren/woofmark#5)
• UI testing with jest-puppeteer Integrates jest-puppeteer for UI testing #541

Blockers to Releasing

• #

[welcome]

Thanks for opening your first issue! This space is protected by our Code of Conduct - and we're here to help.
Please follow the issue template to help us help you 👍🎉😄
If you have screenshots or a gif to share demonstrating the issue, that's really helpful! 📸
Do join our Gitter channel for some brainstorming discussions.

[emilyashley]

cc: @Shreyaa-sharmaa @Shulammite-Aso @NitinBhasneria @keshav234156 @jywarren ✨

[jywarren]

This is great, thanks @emilyashley!! 🎉

One thing that may help is to actually map out a flow chart of dependencies for this set of repos, maybe using a shared Google Presentation? I suggested a flow in these comments we can reference to build on:

#490 (comment)

#490 (comment)

So mapping how each is tied to an upstream or downstream repo through NPM publication (using http://semver.org/ version numbering) will help us map out the required sequence to get new code merged and included down all the way to plots2 and then live on https://publiclab.org.

One thing to bear in mind is how semver conventions for versioning/releases work, which i can very roughly summarize as follows:

https://semver.org has guidance for versioning which we could generally follow; roughly:

0.0.x are bugfixes
0.x.0 are new features
x.0.0 are breaking changes that affect downstream use

so, this lets us make "promises" so to speak (not JavaScript Promises, just the regular kind 😄 ) to downstream libraries that depend on our code, that we won't change any current features they may be relying on without considering the effects and issuing a "breaking" x.0.0 change. And also that if they see an increase of 0.0.1 they'll know it's just a bugfix and safe to merge. They actually indicate this in package.json by specifying a version of the package that accepts bugfix level updates, with a ~ character, so ~0.0.1 (for example). There's a lot more on this in npm docs here: https://docs.npmjs.com/files/package.json#dependencies

Sorry for all the talking! And some of you may be familiar with all this already, but just so we're all on the same page! Thanks a ton!!!

[emilyashley]

Once we have a list of the issues we want to include in the first release, we can keep track of them using

• checkmarks

in this issue description so we know what needs to be done! Feel free to edit the description and list the issue/PR or upstream issue you'd like to include in the first release.

If there's any blockers to releasing we can also keep track of those here and clear them out for each other!

[keshav234156]

ok, So far I have made following PR:

1. Bold bug fix(changed wrapping function for HTML-bold and italic jywarren/woofmark#4)
2. Linting tool (Added eslint,lint-staged and Husky #519)
3. Custom Insert module ( Custom Insert Module #538)

I would like to see all of them in next first major release.

[NitinBhasneria]

I have made this following PR's:
Pending for reviews:

• Popup Disappearing problem solved (Popup Disappearing problem solved jywarren/woofmark#3)
• Drag and drop CSS (Refine drag and drop events to prevent interference with other drag/drop-sensitive fields in downstream use cases jywarren/woofmark#2)
• Add "Related work" section to Title module Add "Related work" section to Title module #534
• Main Image box CSS improved Main Image box CSS improved #467

Merged Work:

• Choose File button UI improvement Choose File button UI improvement #462
• Remove file button added Remove file button added #472
  I think this all can be included in first release. Thank you all.

[jywarren]

Hi all, thanks a lot! Would love to hear from @Shulammite-Aso and @Shreyaa-sharmaa here as well!

Just noting -- in #530 (comment), i made a comment about how an HTML change to the example templates in this repo would need to be copied over into the corresponding HTML code in the plots2 repo for the feature to appear there. And would need to be coordinated with the bumping of the next version of the Editor so that the CSS files are pulled in from the new version of the Editor, at the moment the plots2 HTML changes go live. This takes some good and careful textual warnings and "checklists" in the PRs so that when they're merged we know what has to happen first or immediately after, but it's part of version management so I thought you'd appreciate seeing how it works!

Thanks, all!

[jywarren]

Hi folks working on woofmark -- so, once the woofmark changes are ready and merged into the jywarren/woofmark plots2 branch, we should point this Editor repo's package.json at the latest commit in that forked version of woofmark in a new PR. That will pull all our woofmark changes into this repo, in preparation for a new release here. Does that make sense? Thanks! I'll be reviewing all the woofmark changes today too!

[jywarren]

Also just checking our recent commit history -- https://github.com/publiclab/PublicLab.Editor/commits/ shows contributions from each of the four team members!

And on April 14th, 65915b4, we released v2.0.6. Would this next release, given that it: (a) doesn't break anything downstream and (b) adds some (big and small) new changes, be v2.1.0?