This is great, I'd like to help and contribute

[IjzerenHein]

Dear Alrik,

I stumbled upon your release-notes project on Github by accident. I really like what you are trying to achieve here and fully support this initiative. I myself was actually looking for tools and thinking of writing some scripts to automate release-notes management for my react-native project. One of the goals I have there is that I want to manage my release notes in a human readable file, and yaml seems like a great fit. And then I want to be able to convert that file into a JSON file so I can include it in my react-native project. This seems quite trivial, but one of the challenges I face is that I want to be able to generate two different JSON files, one for iOS and one for Android (sometimes bugs are fixed for specific platforms only). So I'd need to do some filtering on that.

Anyways, what I guess that I'm trying to say is, I'd like to help out, either by building tools or/and testing and verifying the ideas you propose.

best regards, Hein

[alrik]

Wow Hein, thank you for your support offering. I'd be more than happy about any feedback, idea or PR, so yes, let's discuss how you could contribute to release-notes :)

I'm currently implementing the last features for the alpha release of the hub, a web repository for release-notes, where customers or dependents can subscribe to release notes updates.

Once I deployed this, I'll definately ask for feedback. I did not expact such an early support offering, that's why there is no backlog of defined user stories, yet. I guess it's a good time to set this up now :)

But let's talk a bit more about your use case. The json files you want to generate from release-notes.yml are they unique to your particular project, or are they common android/iOS changelog files? (I'm not into mobile app development, so i do not know how release notes are handled with app releases.)

I think it could be a cool feature to add support for flexible tagging of release note modifications. A post-processor/converter could then consider these tags, eg. by excluding specific entries from being written to a JSON file.

Something like:

title: How Tagging may look like
description: >
  In order to give more context to a stated modification we could introduce
  some kind of optional changeset tagging.

releases:
  - version: Unreleased
    improved:
      - title: Adjust submit button color. 
        tags:
          - Android
          - UX
    fixed:
      - title: Fix some crash.
        tags:
          - iOS
    added:
      - Some fancy new feature. 

What do you think in general about this feature? Would that be helpful for your use case?

I already have another converter in my mind that will produce a CHANGELOG.md file from release notes according to this changelog recommendation. My plan was to define a converter interface and add support for invoking converters from the release notes cli tool like: release-notes convert --type changelog or something similar. For sure there will be project specific converters as well. So i might be a cool feature to support conversion with a given node-module (implementing the converter interface)

npm i -g @my-org/my-custom-converter
release-notes convert --converter-module @my-org/my-custom-converter

I hope i did not overwhelm you with my ideas :)

Thank you again and I'm looking forward to hearing back from you.

Best, Alrik

[IjzerenHein]

Hi Alrik,

Wow, you're building a Hub as well, how cool :)) That's actually a great idea to have people subscribe to release-notes updates. How does that work, would it be possible to subscribe through email?

Hey I think you hit the nail on the head with your suggestion for tags. That would cover my use-case exactly. It would be really cool if there was programmable (or CLI) interface in which filtering and formatting is possible. I already wrote some tooling this Sunday and implemented a release-notes.yml to JSON (android & ios specific) and markdown output converter. I'm gonna update my scripts to use tags instead, I think it will work great. If I have some time (I'm part of startup and have way too many hats on..), I'll try to think of a simple generic API that could be used for filtering. I'll possibly do some research into other tools first and see what API structures they use.

As for react-native and mobile development. With all these modern cross platform frameworks, doing release-notes management in a smart and efficient (and good) way, is becoming more and more important. Being able to do it in a single file, and correctly export it to the Google Play store and Apple Store, will same me time on the release cycle, and all time gained is a win. And additionally, having the release-notes in JSON format, will allow me to include it into my react-native project and I can then display the new features to the end-user (when applicable). This kind of information is not always easily accessible through the Play- and App-stores, so having it in the app is a nice feature.

What I was thinking of is creating a 'react-native-release-notes' package, which will basically be a thin layer on top of the 'release-notes' tooling, adding some basic support for iOS/Android/Win filtering, and probably an out-of-the-box Component which can display the release-notes in the App. And maybe for the long term, try to get this into the main react-native repository, because I think everyone benefits from standards and having release-notes in your project is a good best practise.

Oh just one other thing that just dawned to me. What version of node were you thinking of supporting for the CLI tool? No ES6/7 or just use babel for conversion?

Cheers, Hein

[alrik]

Ahoi Hein,

It's so nice to get all this, very early stage, feedback from you :)

the hub will allow people to subscribe to release-notes updates and receive notification by email or via slack. In the future there might be more integrations.

I implemented a simple JSON converter - would be nice to get some feedback from you. And the tagging feature is also in development #2 .

I do really appreciate the idea of a react-native-release-notes package, just tell me how i can support you with this.

Currently the the whole release-notes codebase is tested against node 6, 7 & 8 and it written in plain js without harmony features, polyfills or babel transpilation.

Best, Alrik

[IjzerenHein]

Aloha Alrik :)

The hub sounds great! I know that I would definitely like to receive release-notes updates for certain projects I follow. What is the business case for this, will it will be free for use?

Nice, I'll have a look at the JSON converter.

I like the tagging the way it is setup like this. I only have one concern which may require a discussion. I would like to prevent mistakes through human error, e.g.:

• One person adds a tag called "android" and another person names it "Android"
• A person makes a typo in the tag-name (e.g. "Android " or "andriod")

I can imagine having a schema for tag-names of some sort. Perhaps defined inline in the top of the file (this would be my current preference). Or perhaps a reference to an external tagging schema. One may also argue that modification types are hard-defined in the release-notes schema, so why not have schemas for tagging? I could imagine a react-native release-notes.yml file always referencing (or inheriting from) a set of supported tags schema. And having a linter in my preferred editor which checks the yaml, release-notes schema and tags as your editing. But having said that, I also don't want to overengineer anything at this stage. I guess one step at a time would be perfect. For now, having an inline tag schema would have my preference (it could be as simple as just having an array of strings).

Okay cool, good to know the tooling is written in plain js.

Hey and as for contributing to the CLI-tool, how can I contribute to that? As you mentioned perhaps it's an idea to create a backlog of features/tasks which I can then pick-up when time is available. I can also help by writing tests for the CLI tool or the underlying lib. I just noticed that the lib is called "release-notes-node". Does this mean that it will only run in node? What I guess what I would like to see is that there is a generic lib which runs anywhere (browser, react-native, ..) and a node-js version which includes file-loading and such. What are you your thoughts on this?

Cheerio, Hein :)

[alrik]

Hi Hein, Thanks a lot for writing all these cli tests and everything :)

The hub will be free of charge and open source. Maybe at some later point we could introduce some coporate features in order to fund further development, but for now i'm going to focus solely on building an useful service for the open source community.

I'm also having some concerns regarding tags and human error, my current plan was to introduce some kind of an .release-notes-rc.yml file that can be considered for validation or defining meta data. I'd like to keep the release-notes.yml files as lean as possible. I think an rc-file would allow us to keep custom validation rules separate from the actual content, without restricting the way we are going to handle the whole topic at a later time.

You are right, currently there is only one "reference implementation" in nodejs, but i'm quite open for splitting things up into separate modules in order to being able to support more platforms. Another way would be to either utilize browserify & babelify for generating a browser-compatible release-notes bundle or to implement a dedicated browser lib. I'm currently not sure what's best way is to go. So I'm going to create a follow-up issue for further discussion.

Cheers, Alrik

[IjzerenHein]

Hey Alrik,

Sounds great, looking forward to the hub :)

And I like your suggestion by putting the rules in an rc-file file. I agree this will keep the actual release-notes.yml file clean and will still allow for CI and editors to validate the tags (and potentially other rules). 👍

cheers, Hein

[alrik]

Hey @IjzerenHein,

today i'm happy to announce the release of the hub 0.3.0. It's now capable of user signin/signup, publishing release-notes, subscribing to release-notes updates, and broadcasting release-notes update notifications.

I'm looking forward to hearing your feedback on the hub :)

Have a nice weekend, Alrik

[IjzerenHein]

Hey @alrik. Wauw that's an amazing feat, it looks really good and works very well. I'm very busy at the moment, but I briefly checked it out yesterday and signup & registering was a breeze. Looking really good. Also, I really like the idea of the badges that you can add them to your readme, really nice idea. One comment on that, I noticed that the text is quite long and reads "Subscribe to Release Notes". I would shorten that to just "Release Notes". And then when people click on it, they can subscribe to (or see that they are already subscribed) on hub the page.

I was wondering, would it also be possible to include release notes links on websites? Perhaps even with a reference to the latest version number? And another idea. Would it be possible to automatically have the hub pull in new release notes from github, once they have been pushed there? I think that would be really cool and useful.

Great work man. Like I said, I've been really busy with our company launch, but I still want to help out. I launched a little new project (https://github.com/IjzerenHein/node-web-bluetooth) a couple weeks ago and I'd like to use that as a test-bed for the hub and tooling.

regards and have a great week, Hein

[alrik]

Ahoi @IjzerenHein,

It's been a log time since my last update, but i had just very sporadic time to tinker around release notes. I updated the hub, and the cli tool, so that it is now possible to publish release-notes.yml or even the traditional CHANGELOG.md to the hub in a more automated way (eg. as a travis-ci deploy step).

But i really like the idea to connect github/gitlab and release-notes as close as possible and to allow for automated updates via webhooks :ok_hand:

Anyway: I'd really love to see release-notes in action on node-web-bluetooth and to gather some real-use feedback from you :)

Thanks Hein and have a wonderful weekend. Alrik

[alrik]

@IjzerenHein see release-notes/release-notes-hub#40 and release-notes/release-notes-hub#41 for next iteration on release-notes - github intergration.

[IjzerenHein]

Ahoi @alrik!

Alright, very cool. I too have have had very little time to tinker on things. Instead of node-web-bluetooth I'd like to use my Firestorter lib as a test-case instead. I unfortunately don't have much time for this this week, perhaps next week. I'll let you know when I get around to it.

cheers, Hein

[alrik]

No worries @IjzerenHein, I'm looking forward to your feedback whenever you got the time to dig in :)

Have a nice and productive week. Cheerio