Skip to content
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

Release Process #180

Open
slrtbtfs opened this issue Jul 1, 2020 · 3 comments
Open

Release Process #180

slrtbtfs opened this issue Jul 1, 2020 · 3 comments
Labels
meta Related to the management of the project itself

Comments

@slrtbtfs
Copy link
Member

slrtbtfs commented Jul 1, 2020

It would be nice to have a more well defined release process:

An initial suggestion:

  • We aim for a release roughly every one or two months.
  • To create a new release:
    • A release branch is created.
    • A summary of changes is put in a CHANGELOG file (That does not yet exist).
    • Editor extension maintainers verify that everything still works with the new version.
    • A release is tagged.
    • Updated versions of editor extensions are published.

Related to prometheus-community/community#27

Thoughts? @nevill @Nexucis

@slrtbtfs slrtbtfs added the meta Related to the management of the project itself label Jul 1, 2020
@Nexucis
Copy link
Contributor

Nexucis commented Jul 1, 2020

Editor extension maintainers verify that everything still works with the new version.

That's something nice, but it can be done in another time. It doesn't require to be dependant of these checks to be able to release.

Basically the client can be upgraded after, you just need a compatibility matrix if the client doesn't support future release of the server

We aim for a release roughly every one or two months.

I'm more in favor of doing it when needed. It's nice to have this rule when you have a roadmap/plan of feature/ milestone because like that you can decide what you are going to plan for the next release.

But here, excepting if I missed something, there is nothing like that. I mean the future of this project even if it is sad to say that is going soon to be in a "maintenance" mode where you have most of the time bugfixes and sometimes a new feature to implement.

So I don't think we really need to have a monthly release process. Just doing it when you are feeling it is the good time for that is fine for me.

For the rest, looks good to me

@nevill
Copy link
Contributor

nevill commented Jul 4, 2020

That's something nice, but it can be done in another time. It doesn't require to be dependant of these checks to be able to release.

That's true, extensions are aware of the latest working version of langserver. The editor extension can be released on its own, but align with promql-langserver in major release, say LSP-promql v1.1.3, v1.2.1 are used with promql-langserver v1.1.2, v1.3.1.
Of course, if an updated versions of langserver are published, we have to update extensions accordingly. This is based on the fact that we store the version in editor extension's source.

A release branch is created

How is a release branch formed? Are all the commits of release branch are selected manually? Do we keep working on it for some minor releases?

@slrtbtfs
Copy link
Member Author

slrtbtfs commented Jul 5, 2020

I mean the future of this project even if it is sad to say that is going soon to be in a "maintenance" mode where you have most of the time bug fixes and sometimes a new feature to implement.

That's actually a good thing. This project was originally planned to go into maintenance mode a few months ago.

The point behind "monthly" releases basically was to avoid having bug fixes and new features lying around unreleased for too long. But if there aren't any changes there obviously won't be releases.

How is a release branch formed? Are all the commits of release branch are selected manually? Do we keep working on it for some minor releases?

Basically I'll branch of from master (or whatever the default branch is going to be renamed to) if I feel like doing a release, and open a PR against master. If nobody complains the release is tagged on the release branch and the PR is merged back into master.

In case there are some small fixes required after the release, those are first committed to master, then cherry picked on the release branch and a minor release is tagged.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
meta Related to the management of the project itself
Projects
None yet
Development

No branches or pull requests

3 participants