What's the best way to upgrade from a Drake version that is >3 months old? - upgrade

I have some code using an older version of Drake, and I'd like to upgrade to a much newer version.
How should I proceed?

TL;DR
For the quickest but most informative way to upgrade, you should incrementally upgrade across releases that are 3 months or less apart:
https://drake.mit.edu/release_notes/release_notes.html
More words
For stable public API that needs to be removed, we try to mark old API as deprecated for about a 3-month period; these deprecations should include warnings that direct you towards newer API (or alternatives). In C++, this should show up as a build or runtime warning. In Python code, it should show up as a runtime warning. In Bazel code, it should show up during build process.
At present (2021-04), Drake releases on a monthly cadence, so generally you just need to skip 3 minor versions.

Related

Where can I see the removed SAPUI5 versions?

Can someone tell me why the SAPUI5 version "1.56.16" stopped working? (using CDN).
I know they have been removing some outdated versions, but, I don't see this one on the list.
Or maybe I don't understand which ones are getting removed...
Versions List
Thank you!
You actually answered your question yourself: You can find this information on the SAPUI5 Version Overview Page.
If you check there table SAPUI5 Versions Maintenance Status you can see that 1.56 is an interim version as it never had long term maintenance. So this means this version went out of maintenance when 1.58 was available or rather in case of consumption via FES when 1.60 was available (which was around Q1/2018).
In column End of Cloud Provisioning you can see that the removal of 1.56 was scheduled for Q1/2022. That's why also 1.56.6 is not available anymore.
The schedule when a patch will be removed can be found below in table Available SAPUI5 Versions on SAP Business Technology Platform, but only as long as they are available. As a rule of thumb patches will be removed if they are older than one year or rather with the End of Cloud Provisioning of the respective SAPUI5 version.
It is important to understand that the removal of outdated SAPUI5 versions will happen at regular intervals, each and every time when a patch is older than one year or rather a version is out of maintenance for one year.

How to adjust a TYPO3 extension for newer TYPO3 versions?

I would like to update an extension from the TER to make it TYPO3 v10 compatible. What are the possible solutions and what is the best practice?
Testing and compatibility with older TYPO3 versions should be guaranteed.
It is not clear if it is your extension or not. So if you are not the maintainer, you should check out the repository on github or gitlab if there is a master or develop branch which might already include the changes you need.
Supporting multiple lts versions with the same code can be very tricky but depends on the type of extension and which parts of the core are used. I prefer supporting maximum 2 lts versions at once (that would be 10 and 9 currently) and supporting older versions with different branches. This makes it easier to move forward.
The extension scanner in the install tool will help you to identify the changes which are required but of course those don't cover everything. A good test coverage in the beginning can help you a lot. If you don't got any tests yet, it is never too late to start with those.
Automated tests can run best on Travis or via github actions and there are lot of examples you can take a look at, eg https://github.com/derhansen/gha_demo or https://github.com/FriendsOfTYPO3/tt_address

how to proceed as a module author after a trial release

The problem occurs to me using Perl5 for programming and Dist::Zilla (dzil) for deploying to CPAN. But the question is probably a general one, meaning independent of the programming language.
Problem description
Assuming I'm releasing a new version 0.1 of the module Foo with a new feature called bar. I would like to release it as a trial release (dzil build --trial), to be able the get feedback on the change without forcing it onto unaware users. When I'm doing so using my toolchain, the Changes file will look something like this:
1 Revision history for Foo
2
3 0.1 2019-06-19 17:49:09+02:00 Continent/City (TRIAL RELEASE)
4 - added bar
The packed distribution (for upload to CPAN) is a file like so: Foo-0.1-TRIAL.tar.gz
Until here, everything was easy. But from now on, I'm unsure how to react to upcoming events:
Feedback is positive. No changes needed. Bring the release in production.
How should the new (but unaltered) release look like?
Should I do a release with the same version or count the version up? Should I add a new line to the Changes file (e.g "bring trial 0.1 into production") or alter the existing one (meaning just removing the (TRIAL RELEASE)).
Feedback is negative. Changes needed. Add feature/change baz.
Same questions here. The new change surely needs a mention in Changes. But again: Count version up, or let it be? Make a new entry to Changes or alter the existing one?
This is one of these questions where I feel like: it probably doesn't matter to much, but there must be a "best practice". And in the long term it kind of pays of doing it right.
Question
How should I continue with version numbering and Changes file, after doing a trial release to specifically CPAN?
(General answers, which are independent from Perl and CPAN are also of interest)
My general advice is: if the TRIAL turns out to be a resounding success and there are zero changes aside from releasing the same thing without --trial, you can reuse the version, since at runtime the two tarballs will have identical behavior. If you have to make any changes that may affect users or tests, bump the version. If you're unsure, bump the version -- versions are free. Remember that without a distinct version, other distributions can't distinguish the changes in their dependencies, CPAN clients can't request a specific version easily, etc.
As far as the changelog, it may help that MetaCPAN now includes the changes for any trial releases leading up to the stable release in its changes preview, provided it can parse your changelog and the trial releases are marked as such. (example) So I would just include an entry for each distinct version.

Can I still release a product with iText 2.1.5?

I can not find any link related with 2.1.5 from SourceForge. I wonder whether I can still use this version as a third party component in my product.
Any comment would be appreciated very much!
Sure you can. Search the web and you will find that version easily (e.g. here or here) It is a different question however whether you should still use that version. It is quite old and lots of bugs have been fixed and new functionality has been added. So do the following:
check the license restrictions (LGPL vs. AGPL)
if you don't have a problem with a GPL based license then use the latest 5.X version
if you can't use APGL buy a commercial license or use at least version 2.1.7
if you go the 2.1.7 route do some testing - in many cases it will do its job still fine. If not you'll probably have to fix it by yourself
Update: I would now use openPDF which is a maintained fork based on 2.1.7.

Putting a warning flag on a particular version

I have 4 versions of a file 1.21, 1.22, 1.23 and 1.24. After a month of time I came to know that the version 1.22 and 1.23 have some errors in them. Now I don't want anyone to use those versions. One way to solve it is to delete those versions, but I don't want to delete them. I just want to know a way so that if anyone checkout those obsolete versions they should get a warning or custom message that "don't use this version, this version has some problems".
Is there any way to do this? Let me know, thanks.
I'm not a CVS expert, but you could tag the bad revisions and then write some sort of pre-checkout hook (see this question).
I'm not sure how one would go about implementing it, though. Or if it could work, for that matter.