Please remember to drop releases

[drAlberT]

trafficstars

:) 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 :+1:

[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 [email protected] 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 https://github.com/JasonRivers/Docker-Nagios/issues/37#issuecomment-336828867, or mute the thread https://github.com/notifications/unsubscribe-auth/ABYDjJfA7jywzeoWcFuCW3wgCLJWpbLdks5ssx85gaJpZM4PKKVm .

-- Emiliano Gabrielli