Please remember to drop releases

[drAlberT]

:) thanks

[drAlberT]

Just to clarify, on GitHub I mean ..

[JasonRivers]

I actually switched to branches for this, Branches mean that if there's a problem it can be fixed, but perhaps creating a tag/release at that branch is a good way of doing it.

[drAlberT]

yep :) branches and tags/releases are complementary 👍

[drAlberT]

Anyway .. I think you are adopting a too expensive model to handle the code

My suggestion is to have only a few branches (master, version X, version Y) in which you do:

• development
• maintain X.x.x releases
• maintain Y.y.y releases

You can add (only if and when requested) additional X.Z.z branches . in case you want to support that particular minor release releasing patches for it but, in general you would only maintain a few main branches, tagging on it the releases.

Everytime you release a new patch (in the semver meaning) you drop a new release (tagging it)

example:

• master -> development of the latest features
• branch 4.x -> stable branch for version 4.x.x (it requires php 7.x)
• branche 3.x -> stable branch for version 3.x.x (it requires and supports php 5.x)

Hope to had been clear .. hope to not be boring or annoying too ;)

[JasonRivers]

You are probably right, The reason for having docker hub builds of the version (as either a branch or a tag) was for the users that don't want to upgrade to the latest version all the time "just in case".

I probably won't ever maintain a Nagios3, the reason I created this image was that everything I found at the time was either Nagios3 or didn't really work, But I will probably continue to maintain "the latest nagios4" when Nagios 5 drops, at least for a while.

Overall, it doesn't actually take a lot of maintenance, Both dockerhub and Travis build when I commit and tell me when I'm being a muppet, and I generally build and deploy to a test environment before committing to master.

I haven't committed to any of versioned branches for a while, I can probably just create tags for those now, and as you say, maintain a 4.x branch instead.

Thanks for your input.

[drAlberT]

great. Mind the fact that if you choose to switch to tag you should tag **master** branch at the point you created the matching release branch, not just tag the release branch directly. Thanks for your work

…

On Monday, October 16, 2017, Jason Rivers ***@***.***> wrote: You are probably right, The reason for having docker hub builds of the version (as either a branch or a tag) was for the users that don't want to upgrade to the latest version all the time "just in case". I probably won't ever maintain a Nagios3, the reason I created this image was that everything I found at the time was either Nagios3 or didn't really work, But I will probably continue to maintain "the latest nagios4" when Nagios 5 drops, at least for a while. Overall, it doesn't actually take a lot of maintenance, Both dockerhub and Travis build when I commit and tell me when I'm being a muppet, and I generally build and deploy to a test environment before committing to master. I haven't committed to any of versioned branches for a while, I can probably just create tags for those now, and as you say, maintain a 4.x branch instead. Thanks for your input. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#37 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABYDjJfA7jywzeoWcFuCW3wgCLJWpbLdks5ssx85gaJpZM4PKKVm> .

-- Emiliano Gabrielli