Skip to content

Change the development flow in NES.css #409

@guastallaigor

Description

@guastallaigor

Is your feature request related to a problem? Please describe.
I think we should change a little bit the way we are doing things in Git/Gitflow/Release in NES.css.
In my opinion, we should be a little more close to what Vuetify does.
To be more specific, this right here:

The PR is submitted to the correct branch (master for bug fixes and documentation updates, dev for new features and backwards compatible changes and next for non-backwards compatible changes).

Like we are getting a few documentation updates, that should be already be in master, but instead are in our develop branch and is going to be out in the next release, and that should take some time.

Describe the solution you'd like

  1. All documentation updates that aren't regarding new feature requests, be direct to the master branch (high priority);
  2. Create and add a checklist to our PRs (medium priority);
  3. Add an Ability to deploy NES.css website, without having to generate a new release (when we get documentation updates that affects a component in the website) (low priority).

Describe alternatives you've considered
Just keep the way we are doing things right now.

Additional context
N/A

Metadata

Metadata

Assignees

No one assigned

    Labels

    discussionDiscussion of changes or bikeshedding

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions