[SERVER-3823] new version package release process should be reviewed Created: 13/Sep/11  Updated: 06/Dec/22  Resolved: 28/Apr/17

Status: Closed
Project: Core Server
Component/s: Packaging
Affects Version/s: 2.0.0
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: ttt Assignee: Backlog - Build Team (Inactive)
Resolution: Done Votes: 0
Labels: build-needs-definition, build-planning
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

centos 5.6 x64 rpm


Assigned Teams:
Build
Participants:

 Description   

major version upgrades that might break production servers as is in this case of 2.0.0 should be done manually

i see that mongo-* 1.8.3 rpm were renamed to mongo18-* and 2.0 was introduced as mongo-* which resulted in auto upgrade to new version on my servers.

i would advise to release new version as mongo20-, mongo22- and keep old as mongo18-*, no renaming.



 Comments   
Comment by Ernie Hershey [ 28/Apr/17 ]

Upgrading across MongoDB major release series versions now requires explicit package repository configuration updates with separate repos for each release series - e.g.

https://repo.mongodb.com/yum/redhat/7/mongodb-enterprise/3.0/
https://repo.mongodb.com/yum/redhat/7/mongodb-enterprise/3.2/
https://repo.mongodb.com/yum/redhat/7/mongodb-enterprise/3.4/

This will prevent inadvertent automatic upgrades and gives users control over which release series packages their packaging system sees and lets them upgrade to.

Comment by Krzysztof Wilczynski [ 21/Sep/11 ]

Eliot is quite right. This might not be package managers friendly. Plus, a lot of people is using confirmation management tools like Puppet and Chef (or whatever) which quite often manage packages installed on the system (or have the ability to install / deploy new packages) and introducing this may cause problems there.

You guys should keep in mind that in majority of cases there is a systems person looking after Mongo deployments, not necessary the developers. Therefore consistency and manageability is always a plus and will make all the Systems Administrators love you forever.

Having binary packages from you guys is already a huge win

On that note... It would be better if either RPM and/or DEB would not (preferably) start new version of Mongo (mongod in this case) automatically. This is not quite desirable in production (or whatever) environment and may cause issues is something will go wrong, especially if any automation and configuration management is in place.

I would rather have a message saying that Mongo is ready to use and you can start it straight-away, plus you can enable it to start automatically after a system start-up etc ...

Some packages are already like that and it makes life of people in Operations more bearable very much so

KW

Comment by Eliot Horowitz (Inactive) [ 13/Sep/11 ]

We were thinking of something along these lines - but not exactly sure what.
Some people want auto-upgrade.

Generated at Thu Feb 08 03:04:10 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.