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

Master Behind Release Tag #14306

Closed
claytondaley opened this issue Apr 2, 2019 · 10 comments
Closed

Master Behind Release Tag #14306

claytondaley opened this issue Apr 2, 2019 · 10 comments
Labels
answered For when a question was asked and we referred to forum or answered it.

Comments

@claytondaley
Copy link
Contributor

I have an instance of Matomo that I update using git. I pulled master today only to be notified (in the UI) that I don't have the latest version (3.8.0 vs 3.9.1). I came here and confirmed that master is behind the current release tag.

Is this intentional? If so, why?

@sgiehl
Copy link
Member

sgiehl commented Apr 2, 2019

ping @mattab

@tsteur
Copy link
Member

tsteur commented Apr 2, 2019

shouldn't you check out 3.x-dev?

@claytondaley
Copy link
Contributor Author

I'm not developing. I'm pulling to a production machine.

@tsteur
Copy link
Member

tsteur commented Apr 2, 2019

Yes the same, I mean you would need to pull 3.x-dev and not master?

@Findus23
Copy link
Member

Findus23 commented Apr 2, 2019

@tsteur Normally the master branch is up to date with the stable release, but it seems like there is no pr like #13996 for 3.9.0

@claytondaley
Copy link
Contributor Author

@tsteur I'm not exactly sure how you manage PRs here, but dev is usually treated as an unstable branch only appropriate for development machines. For example, there's no guarantee that upgrade scrips are present for the changes merged from PRs.

@tsteur
Copy link
Member

tsteur commented Apr 2, 2019

@Findus23 totally forgot we're still doing this. I suppose we need to stop possibly with Matomo 4. Think we discussed a year ago or so. Since it's not recommended / less secure etc.

If someone wants to still use git, they can check out specific release versions.

@claytondaley
Copy link
Contributor Author

claytondaley commented Apr 2, 2019

I don't think that's the right advice, but you can certainly deprecate master in this repo (e.g. strand it at 3.x) and tell users that they need to merge the appropriate tags into their own, local release branch (the name being totally arbitrary).

I'm sure I used a git repo to merge in a fix/PR I had submitted but had not yet been released. I'd argue that it's important to have that option even if you don't maintain a production branch in the upstream repo.

@claytondaley
Copy link
Contributor Author

FWIW our release scripts will refuse to run if we haven't checked out master and we use branch permissions (on bitbucket) to (1) limit who can commit to master and (2) prohibit rewriting of master. You can "roll back" a change by committing the prior version, but it provides a clear audit trail. We go to the trouble because we're a Healthcare IT company that needs the audit trail, but it's a nice pattern.

Obviously, you should run your business as you see fit, but that pattern is designed to ensure that git pull on master returns the current stable version of the software.

@mattab
Copy link
Member

mattab commented Aug 9, 2019

I try to keep master up to date with releases but sometimes forget. So it's not safe to rely on master branch. please instead use the Git tag named: https://builds.matomo.org/LATEST

@mattab mattab closed this as completed Aug 9, 2019
@mattab mattab added the answered For when a question was asked and we referred to forum or answered it. label Aug 9, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
answered For when a question was asked and we referred to forum or answered it.
Projects
None yet
Development

No branches or pull requests

5 participants