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.
Related
When I run composer updates I'll occasionally get messages that packages are abandoned and I should use a different one instead, like Package webflo/drupal-core-require-dev is abandoned, you should avoid using it. Use drupal/core-dev instead. I don't have experience with Composer so I'm curious as to what is seen as the best practice for replacing outdated packages.
Where do these messages come from? I'm unsure if the source is always reliable.
I think the best practice is quite clear from the message "you should avoid using it". How/When to do this is not as clear. Abandoned packages will not receive updates, but composer will not be able to tell you how difficult it will be to transition to the recommended alternative. It might be that all you have to do is replace the package, because it was only a name change or having to modify your code as well.
In your case webflo/drupal-core-require-dev only contains a composer.json and the required packages match with what the alternative drupal/core-dev provides. That means replacing the package should be as easy as changing the name in your composer.json and then do a composer update drupal/core-dev.
For packages where the answer is not as straightforward, you have to rely on automated/manual tests to see if everything still works. Static code analysis tools might help as well. You will have to set them up before you do the change, so that you can see how their output differs and fix the new issues that come up.
You should do the switch to the new dependency as early as possible. Leaving it in will likely cause more work in the future when replacing it and might pose a security risk (if it is outdated and insecure). I understand that this is not always possible and using something like roave/security-advisories to tell you when there are known security issues in a package might help postponing it and giving some sense of security.
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.
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.
I'm writing a Perl module and right now I'm including in Makefile.PL all of the dependencies. The only problem is I have all of the latest versions of the modules required, but I don't want to limit anyone who has early versions (and either can't update them or requires older versions for old code). Is there any way to find out what would be the lowest version usable with my module without downloading and testing all of the versions? Thanks!
No, there is not an automated way to tell. You probably want to start with reading the Changelog for each module and seeing what changes have occurred.
Ever heard of Dist::Zilla? It won't help you with the version problem... but it helps you with a lot of other stuff for creating, maintaining and releasing modules. As mentioned by others, the only way to know the versions working is write tests and test against them...
It is this sad moment to a developer's life that he has to maintain and fix legacy code... In my case I have to deal with a modified (core scripts) tinyMCE 3.2.2 which I have to update to the latest version in order to play in IE9+...
So my question is if there is a way to check which files have been changed since version 3.2.2 and try to update only those cause it is an overkill to check all the code for the modifications...
Thanks in advance
I fear there are so many changes in so many files that most of them have changed since then and in order to work with IE9.
If possible you should never ever modify the core code. Instead use custom plugins if possible.