I recently had to upgrade my Gitlab server. I found out that gitlab-7.8.1_omnibus is too old and there is no direct way to update the current version to the latest version gitlab-ee-12.7.6-ee.
The best way I've found is to install a new server with the latest version of Gitlab and ask the users to transfer their data to the new server.
Is there a way I can transfer the data for the users?
I would like to prevent this from happening again. How do I make sure my Gitlab server is updated evey time a new version is available.
Do I must to run 'yum update' before I run the Gitlab update?
I.
GitLab 7.8.1 is indeed a very old version.
You can avoid upgrade path and just move Git repos, if your number of projects and their customisations and integrations is low.
Every clone of git repository is supposed to have all (or nearly all) history.
So you can just:
create a matching project on the new GitLab server
add a new remote to your git clones on your machine git remote add origin ...
push to the new remote
II.
You can still try to upgrade your current server in several hops, see upgrade recommendations:
We recommend that you first upgrade to the latest available minor version within your major version
Old versions I could find are:
8.0.0 as the oldest Docker image
7.10.0 as the oldest deb\rpm package
7.14.3 as the latest in 7.* release as deb\rpm package
First make sure you minimize any customisations you have in /etc/gitlab/gitlab.rb as those parameters change a lot across versions, and require manual reconfiguration.
Then you can try:
upgrade to 7.14.3
then to 8.0.0
then to the last in 8.*
then to 9.0.0
etc
III.
Once you have a stable recent version of GitLab server:
GitLab publishes new Major release yearly, and every Major.Minor release monthly (22nd day of the month), see maintenance policy, I really recommend upgrading every month
wait for a couple of weeks though, as they often release patches for bugs quickly found by other people
review release notes
read upgrade documentation
don't forget to backup
upgrade
Related
Why is 3.2.0 not available here any more? https://downloads.apache.org/spark/
Just to be clear, it was here until a few days ago. This link is checked into our internal repo. Realized this artifact is no longer available when the build broke.
Need to make sure we don't go to prod with this version if there is any known major issue with it that caused it to be taken down.
Download Spark page has only the latest version of every major version of Spark. If you want a specific version not listed on the main downloads page, you can use Archived libraries link.
I am currently using node 6.1 in my project.
I want to upgrade it to latest stable version now.
Before doing that I want to know what are the breaking changes introduced in all the versions in between 6 to 12
Is there any place I can get all these breaking changes for the node versions.
I've found this page to be the most helpful list of all major/minor/patch changes:
https://nodejs.org/en/blog/release/v16.0.0/
Another good resource to find changes to all the different major versions, is the changelog archive on nodejs' github:
https://github.com/nodejs/node/tree/main/doc/changelogs
Is there an explanation why NodeJS latest version is 6.2.1 but the LTS is 4.4.5? It might seem odd but shouldn't they stabilized version 5 first before working on or releasing version 6?
https://nodejs.org/en/
The reasoning behind this is that Node works to a 'LTS schedule':
New major version releases (i.e. the x in x.y.z) are created from the master branch every six months - even-numbered releases in April, odd-numbered releases in October.
Whenever a new odd-numbered release comes out, the previous even-numbered release moves into LTS, meaning there should be no breaking changes to that version from that point on.
The LTS version will be supported for 18 months, after which it will go into maintenance mode for 12 months, meaning it will only receive critical/security related updates. Because of this, there will never be more than two LTS versions active at the same time.
If it helps you visualize it, there's a diagram of the schedule on the Node LTS GitHub:
This allows there to be a predictable release schedule and migration path for those who have to support their Node infrastructure long-term, while keeping the pace of development moving for those who want to stay on the cutting-edge of new features. Bear in mind that under SemVer (the versioning scheme that Node uses), breaking changes are only allowed in major-version releases - having a regular schedule for these coming out ensures that these changes can be tested before they get added to an LTS version further down the line.
For more info, I recommend taking a look at the Node LTS GitHub - this is where I got all this information from, and it's a pretty helpful resource.
Is there any way I can go back and install a older version of Cygwin?
Say I want the 1.7.9 version, but the setup.exe in the Cygwin website always point to the latest release?
http://www.cygwin.com/setup.exe will always point to the latest release. The only previous release available at cygwin.com is the 'setup-legacy' file, which is version 1.5.25 and is compatible with older versions of Windows. Downloading older versions of Cygwin is discouraged because of incompatibility with the latest available packages.
That said, if you are certain you want an older version of setup.exe, the only way to get it would be to find the file mirrored elsewhere. Simply google the specific version you want, and you should be able to easily find what you are looking for. download.cnet.com, for example, has many previous releases: see for yourself.
In summary, there is no 'official' way to get previous Cygwin releases, so you will have to find a mirror of that specific release.
Yes, see this answer but ignore the parts about Postgres
https://serverfault.com/a/532412/123651
Install an old version if you have to. Someone maintains a historical archive of Cygwin versions.
Browse the time stamp of the setup.ini file you need: http://www.crouchingtigerhiddenfruitbat.org/Cygwin/timemachine.html
Copy the address of the folder (not index.html)
Run /setup-x86.exe -X with the -X option to ignore setup signatures (they aren't archived).
Paste the address into the dialog to choose your download site. You will then see a snapshot of packages available during that time.
Then pick the Cygwin base package to get an older version.
Download any setup version from https://cygwin.com/setup/
When installing a .MSI file using msiexec in silent mode, is it possible to automate it such that on installation failure it rollbacks to the previous version? Assuming that on installation an older application version is already installed.
Yes, restoring the old application version via rollback upon an installation failure is actually a built-in feature of Windows Installer, but you need to configure things correctly to get it to work as you require.
Windows Installer rollback will work as you request if you use: 1) a minor upgrade or 2) a properly sequenced major upgrade that uninstalls the older versions after successfully updating all files. If the major upgrade is set to uninstall the old version before installing the new, the rollback is not available since the uninstall is already over, and the new installer will hence leave nothing installed if it fails and rolls back.
Important: For minor upgrades and for late uninstall of old version in major upgrades to work correctly, all MSI component rules must be followed 100% accurately.
When thinking about a major upgrade that uninstalls the old version after updating, you can view it as a patching operation without having the update packaged as a patch. Windows Installer will actually run a diff on the old and new version and then implement only the required changes, leaving the rest of the application untouched. Depending on the application structure and number of files, this can be significantly faster to install as well.
Late-sequenced major upgrades are also a way to prevent configuration files from being reverted to their original installation status during upgrades. This is a classic issue where config files are changed after installation, uninstalled during a major upgrade and then being reinstalled giving the impression that they are reverted, when they are actually freshly reinstalled.
I have written about Windows Installer Rollback before. Might be worth a read.
No, this is not possible. A major upgrade uninstalls the old version before installing your new one. So when the new install fails, the old version is already removed.
There is a possibility but it involves changing the upgrade sequence which is not always an easy thing to achieve. You should move the RemoveExistingProducts after InstallExecute action
http://msdn.microsoft.com/en-us/library/windows/desktop/aa371197(v=vs.85).aspx