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
Related
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.
I have to refactor a few very old TYPO3 extensions. they are compatible with ^4 but the company I'm working for now needs them for ^8 (the development for this extensions stopped for whatever reason).
I was wondering what is the best approach for me to get this task done -
are there some major resources I could use to get into that topic?
or a general changelog for TYPO3 extensions based on the version up from 4-9?
Any information is much appreciated.
Trying best to answer this, it's up to you how you maintain your site. Off course you need to check the complexity of the extension you build.
Check a few parameters below:
1. Complexity of the extension
Off course you have a big challenge to maintain code (Probably PI-Base extension). Your code should work with TYPO3 8.x as well as PHP 7.0.
2. Code Scalability
A simple thing, your code must be clean so understand better.
Now, you have two way to maintain your extension which is:
Re-build
Use existing extension (Migrate & make this compatible)
Re-build Extension
If you don't have complex application in your web site, you can follow #Aristeidis Karavas and rebuild the completely new extension (Extbase approach off course).
I'll recommend, re-develop for better quality product and to get optimized speed! What do you say?
Migrate Extension
For TER extension (which is available at extensions.typo3.org) might provide migration extension, such as EXT:tt_news to EXT:tx_news. For the custom extension, you can write your own SQL script which migrates your extension data to the new extension.
Compatibility Extension:
You can use compatibility extension available at TER which provide some easy solution to map TYPO3 classes.
Useful Links:
Here is some useful link could bring you to the bright side and will make your stuff easier:
EXT:compatibility6
EXT:compatibility7
Blog: Upgrade Guide
Bernd has given deprecation lists Links here
Hope this will help you!
I feel like this is a feature request/question for Github devs but since Github by default doesn't show you python 2 or 3 (but instead just python), how to easily tell other than cloning it or browsing in source code, assuming the Repo. document doesn't say (and often they just show pip without specifying whether it is pip2 or pip3. I know I can just do pip search as well as I prefer if I can just see it right in the browser.
Maybe there is a chrome plugin but my googfu has no luck finding it thus far.
It seems that you are asking for GitHub to tell you if a project or repository is Python 2.x or Python 3.x, and that is just not reasonably possible. If it is available through pip (pip2 or pip3) you can query that way (already mentioned), but it is worth explaining why GitHub cannot do what you ask :
Python packages, projects, and/or code are not Python 2.x or Python 3.x (exclusive or), rather, it is possible two write code that works with either.
GitHub could try to infer the prevailing version of Python within a repository, however, if they did so programmatically (even using sophisticated AI) it would be wrongs far too often.
GitHub could try to force users to pick one, which would alienate many, frustrate many more, and generally provide no significant benefit to the community.
Even if GitHub forced folks to choose, it is surprisingly common for authors to know know if their code will work fully in one version or the other.
Although you could envision GitHub trying to enforce designating repositories as "Python 2.x" or "Python 3.x", this makes little sense (see first bullet item) and would give the Python ethos community a severe allergic reaction since it's antithetical to the culture.
TL;DR: Github currently doesn't support distinguishing between Python 2 and 3 in the repository language statistics.
Assuming you're referring to the Github language statistics on the front page of a repository (see screenshot of example repo below with red box around programming language statistics):
This will not distinguish between Python 2 and Python 3 code. Apart from cross-compatability reasons, part of the reason why is that Python 2 and Python 3 code files sometimes share the same file extension names, and the Linguist library which is used to calculate these statistics does not differentiate between them.
You can see this section of the languages.yml file in the Linguist Github repo to see what's considered a Python file or not. Note that there's no distinction anywhere in the languages.yml between Python 2 and Python 3 code.
I am new to sakai, i want to add my own tool in sakai source code like announcement,syllabus...etc That tool having some my own functionality for this what i have to do, how can i develop my own tool in sakai.
Thanks.
Use one of the archetypes to get you started, then customise it. When you are comfortable you can change the UI layer to be whatever you like.
https://confluence.sakaiproject.org/display/BOOT/Developer+Tools
If you are looking for a solid "base" tool shell to begin with tool development my recommendation would be to start here: "Sakai Wicket Maven Archetype". There are a few other very good archetypes available but are often outdated and may cause you some problems based on my experience. This has been the one I've had the most success with.
This uses Wicket but does not mean you have to use Wicket to develop further with it. Make sure to pull the 1.2 version as last check the binaries for the others were not available yet so replace -DarchetypeVersion=1.4.1 with -DarchetypeVersion=1.2 It will compile and deploy successfully as a tool "as-is" that you can modify as needed. It also allows you to code in Java to directly access the sakai API and pull from its database or even add your own tables. I've successfully used it with NetBeans 8.0.1 and MySQL 5.6 under Windows 7 with Maven 3.2.3 and Sakai 10.1.
The code is well-documented and is no-frills but with enough varied functional use examples to allow you to do "almost" anything you want. The wicket manual is 600+ pages but in my experience you should be able to accomplish a lot just by looking at the code in the archetype.
I've got a (dirty) production installation of Simple Machines Forum (SMF 1.1.13). It was a clean install, once... about five years, twenty updates, and 40 mods ago. Not to mention the custom code that was patched directly into the code base. This started as a for-fun side project, and didn't have any code management practices at the get-go.
Now SMF 2 is (getting closer to) going live, and I want to upgrade. But without leaving the custom features behind.
Keep reading, this is a general software management question, not an SMF support question...
I'm trying to figure out the best way to port the custom features into the new code branch.
In some cases, the custom 1.1.x functionality will already exist in 2.0. Yay, no work for me!
In some cases, there will be mod packages versioned for 2.0, and I can just install them directly on a clean SMF 2 build. Yay, minimal work for me!
In some cases, the code port will be fairly straightforward between the two versions (e.g. a few small changes in queries or global variable construction). (I've ported a few features/mods back from 2.0 to 1.1.x, so I'm starting to get familiar with it.)
In some cases, I'm just going to have to redevelop the features mostly from scratch.
Those last two options are gonna be hard to manage.
Any suggestions on how to port a large number of changes from one branch to another?
When it's not my own in-house code, that is. Here's my initial plan:
Diff between a clean version of 1.1.x and my "dirty" production code
Map each line diff to a feature ("That code update is the custom tagging feature, gonna have to port it line by line, and that one over there is the gallery, I can probably install an updated mod.") This would be SOMUCHEASIER if there were a diff tool that generated a consolidated report, instead of having to go through scores of files one at a time. Google and SO searches didn't find a tool like that-- Is there one?
Install a clean 2.0 branch
Install the available updated mods
Roll up my sleeves and go through my diffs feature by feature (this? is why I need the consolidated diff report. It would be hell to do page by page.) and build them back in.
Any better ideas? (Pointers to release management info are welcome, though of course with the caveat that it's not actually my code so I have limited control.)
Otherwise? I fear my options are ditch the custom features (not really feasible) or stay on the old branch. Both suck. Help!
tl;dr: Point me to a diff tool that will do consolidated file-by-file diff reports for entire directories. And/or help me figure out an easier way to migrate my custom code.
Your plan is generally the most practical approach, although I would say that you're heading in the wrong direction by looking for code-level differences. With no version control over the project lifetime and with no concise record of applied changes, in examining differences at the code level you are looking for a level of detail that may not give you the information you need to apply the same changes to a new implementation.
Move away from thinking of code-level changes and consider application-level feature and behavioural changes. What features have your changes introduced? In what ways does your application now behave differently due to your changes?
You say that there have been many unversioned changes over a long period - you will fail to find all the changes no matter what tools you have at your disposal and you will still need to consider the feature and behavioural changes that exist to fully represent the same features and behaviours in any upgraded implementation.
You know your application well, you use it and you do appreciate the feature changes that you have introduced even if you may not realise this.
Install a vanilla 2.0 release
Apply all appropriate mods
Apply relevant styling
Use the new system, note the differences in behaviour and develop from this a set of required features
Your feature set does not need to be complete - don't stall at the stage of trying to figure out all required changes, this will take too long.
Apply features gathered from most recent feedback (ideally through revertable mods)
Note the differences in behaviour at develop from this a set of required features
Repeat