We are planning to migrate our old legacy code which uses commons-httpclient-3.x to httpclient5.x . But found that its going to be complete rewrite as lot of classes/packages removed.
Tried migrating to httpclient4.x , seems to be having lesser changes compared to 5.x migration.
But want to know the support plan for 4.x and 5.x from apache/community. As per maven repo, last release on
4.x was on Oct - 2020 where as 5.x was Jan - 2022
Can i expect fixes/code changes in 4.x for the next 4/5 years atleast if i use it instead of 5.x?
Please share if anyone has idea on this.
I posted the same in apache httpclients forum. I got replies.
Reply from 'Oleg' (one of active members in apache httpclient community)
Both branches will continue to be supported, especially 5.1 and 5.2.
The reason for last releases being so far in the past is simply we have
not been getting that many bug reports and there have been no major bug
fixes that would warrant an immediate release.
5.1 and 5.2 releases though can be expected soon.
Can i expect fixes/code changes in 4.x for the next 4/5 years atleast if i use it instead of 5.x?
We are all volunteers here. No one is gets paid for providing
HttpClient support. We can all go away any time. That is the whole
support plan.
One thing I can guarantee however that there will be no feature
development for 4.5 any more. We will likely be doing fixes for severe
and security issues in 4.5 going forward.
Reply from Michael Osipov
At some point in time we need to decide when to cut off 4.x. I don't see
a reason to keep this branch alive for the next five years. Given that
very little work on this project it would make sense to reduce the
amount of supported branches.
Reply from Gary Gregory
The sooner the better for a 4.x cut off IMO. There is a lot of complex code
in total for versions 3, 4, 5, and very limited human resources.
In Short: We can safely migrate to 5.x. I guess this answers for many developers who are looking for an answer like me.
Related
Which is the more feasible strategy for version upgrades when you are multiple versions behind. For example from 6.4 to 2005.
Should we really do a version by version approach as SAP suggests. I understand it's recommended way but still.
Any one can share their experience regarding this?
What difficulties could be faced when directly migrating multiple versions?
Thanks!
There are several approaches you can take. Which one you take depends on the knowledge your team has and with the amount of customizations you already performed.
Step by Step
This is the recommended way by SAP. This is a more secure strategy, where it's very clear what changed between different versions. With every version, you will experience build failures, startup failures and possibly even data issues that need to be migrated. But it's very clear what version caused those issues. With the SAP help and the upgrade notes, you should be able to easily find what was changed, and how to fix it. Disadvantage with this approach is that you need to download, unzip and build for every version, and that takes time. Sometimes you even need to fix the same code twice, when the implentation was changed multiple times
One Shot
With this approach, you go straight to the latest version. You just put your custom code in the latest version and just see what build failures you get.
With this approach, it will be harder to figure out what exact version upgrade caused a specific issue. You should still check all upgrade notes, to make sure that no migrations are needed. Advantage is that you only perform everything once. If you have an experienced team, this is a feasable approach. If you have a new team, be carefull with this approach. You might encounter some difficult errors where you won't be sure what version caused them, so finding info in the SAP help might be harder
Hybrid approach
A third option would be a hybrid approach, where you upgrade several versions at once (For example to versions that contain big changes, like with the addition of backoffice in 6.3). This makes it easier to apply changes for those big changes, while you don't have to go through every version one by one.
Conclusion
I've tried all approaches in the past. The step by step approach takes a lot of time, but makes the changes easier and clearer. With the One Shot approach, you only need to download the latest version, but it might be somewhat harder to find the bugs. If you have an experienced team, you should go for the one shot approach. When you are a lot of versions behind and there were big changes, you could go for the hybrid approach
I had a similar requirement of upgrading from version 6.2 to 2005, I went with the One-Shot approach as explained by Yoni, and the biggest challenge I faced was due to Java version change.
I believe One-Shot approach and Step by Step approach will take a similar amount of time in the major version upgrade, though Step by Step approach is safe but redundant. My personal favorite is One-Shot.
I recently did a platform upgrade from hybris 6.7 to 2005 and did it step by step, mainly because of the java version change and, other than that, there were certain migration steps in each intermediate version that were needed to be done. Also the customer had a lot of custom promotion rules and they needed some special care.
In my case, the process in each step was this:
Upgrade to new version - there is an help.sap.com page for each step, I recommend you follow it and go through each of the section to see what applies to your project, e.g Upgrading Platform from 6.7 to 1808
Compile the project - some deprecated things will be removed in some steps and you have to refactor where needed. This step took me the most amount of time
Start the hybris server - after you finish the refactoring and your project builds successfully with ant clean all there is the possibility that the platform will fail to start due to some (now) incorrect xml config. The "good" part here is that you can see in the console what the problem is and the fix should go faster than the previous step.
Perform the necessary upgrade steps - here is the tricky part, once your platform starts you have to perform the necessary upgrade steps for each extension and add-on that needs it, otherwise you risk working with some broken business logic. You need to do some regression tests and check that everything works as it should.
All in all, an upgrade takes time and depends on how many versions you have to go through, but I think taking it step by step is the most efficient way to accomplish it.
It's over a year that we have had a commit for QueryDSL.
https://github.com/querydsl/querydsl
Shall we consider this project Dead or is it moving to a new group? I guess the old team have no plan to maintain it anymore. New JDKs arrive every 6 months and I guess this project will be out of date sooner than we expect. Any news or compatible alternative?
I joined the querydsl team several years ago but lost interest due to the time constraints of having a full time dev job. I am however still a member of their Slack workspace and as of today, no-one has posted in the #general channel since July 2018. When I was active, the channel was busy most, if not every day.
I'm led to believe that Timo Westkämper (owner) is too busy / has lost interest, as with most (all?) other devs excluding Ruben Dijkstra who has contributed a great deal towards the project but is busy with University. He intends to come back. I heard that Atlassian started contributing but there was no-one to up-skill them and deal with their prs, so they ducked out.
In summary, AFAIK, no-one is working on the project and it would appear the owner has lost interest. I'm considering JOOQ but worry it's somewhat of a one-man-band too. If Lukas moves on, we could be in a similar situation.
I think querydsl is a great tool and it's free for all RDBMS, compared with better maintained JOOQ. In my personal opinion, I'd like to see, minimally, querydsl-sql forked by the open source community, its dependencies reduced (it brings in a lot for what it is) and its Java version brought up to date. Perhaps querydsl-jpa could follow. These, IMO, are by far the most used jars and the more specialised functionality could be dropped, E.G.
querydsl-collections
querydsl-hibernate-search
querydsl-jdo
querydsl-lucene*
querydsl-mongodb
querydsl-scala
querydsl-spatial
querydsl-sql-spatial
querydsl-sql-spring
UPDATE
Timo has approved the handover of the project.
UPDATE
The querydsl team is back in action with querydsl 4.2.2 in Maven central as of 22-Nov-2019 and querydsl 5 in the pipeline. Thank you to the new team members for breathing life into this excellent project.
Several days ago, Mirth Connect version 3.3.0 was released. Noting the great new features, we decided to upgrade immediately (just days after the initial release). We followed these Upgrade Guide instructions during the upgrade. However, the specifics of upgrading from 3.2 to 3.3 are missing from these Upgrade Guide, so we did not suspect much to change on the way Mirth should be implemented...
During this process, we ran into a handful of issues that caused our production channels to go down for several hours (†).
It would have been really nice to have specific information for this upgrade. Some issues that would have been really useful to know beforehand (just examples, no need to actually answer):
Are you changing the default toString() method for objects/arrays to return JSON representations?
Does this upgrade include a db migration, meaning we can't revert to
previous version once upgraded?
Because code templates are now children of "libraries", will we need to access the code template through the library, or will we be able to call it directly (as it was in 3.2)?
A solid documentation like this would have allowed us to understand the full gravity of what needs to be accounted for when upgrading. Typically, Mirth has some documentation for each minor release. But even then, the documentation is very terse. Would it be possible for the Mirth team to start being very explicit with what the upgrade entails?
The Rails Upgrade Guide (obviously much larger team, so can spend more bandwidth on this spec) provides a really great example of what an upgrade guide should entail.
† yes, yes, I learned my lesson, I won't upgrade immediately to production anymore
The Release Notes page will give the lowest level of changes to the application, but you're right in that a better documentation is needed.
Do you have any dates for a first RC of the Brixton release train?
SpringBoot 1.3.0 has evolved and contains many fixes and features that we (and probably many other people) require.
In addition, many bugs and issues have been fixed in Spring cloud since Angel.SR3. Not being able to build our software on a fixed release (other than a SNAPSHOT) is a killer for us :-(
In general, it would be very helpful if SpringCloud adopt a faster release cycle with more frequent RCs or Milestones so bug fixes are available sooner. This is quite important for young projects like this one where a high number of issues are likely to appear early in its life.
Thanks for your answer.
SpringCloud 1.1.0.M1 has been made available September 14th. Based on SpringBoot 1.3.0.M5
I'm looking for a version numbering scheme/pattern/system for an application that is currently branched into several versions with shell game style release dates. This has made versioning a nightmare. I'd like to just use the typical Major.Minor.Revision however this will break down for me quickly the way things are presently run around here.
Here is my inventory...
1.0.0 - Production version.
1.0.1 - Production revision version with bug fixes.
1.1.0 - Production minor version with new features due in July (regulations compliance, must be done).
1.2.0 - Production minor version with new features to integrate with not-yet-released-still-under-development System A.
2.0.0 - Development major version "2.0" of the product (code migrated to newer platform, usability improved).
And to make it more fun, they are planning another project (new features) for integration with a different system.
1.3.0 - Production minor version with new features integrating with System B.
Adding to the complexity is the fact that we don't know exactly when (read: the order in which) these will "go live". If one of the systems we are integrating with gets delayed, then management changes the release schedule. So version 1.2.0 today could get delayed and then the build we tagged as 1.3.0 would drop first. Coordinating with QA is difficult enough already without changing version labels at the end of the cycle.
Questions? Thoughts? Small furry animals?
peace|dewde
Sounds to me like you don't want to use version numbers specifically.
You can use codenames, (Windows did this with each of their releases before they were released).
You basically need something more than numbers to distinguish in house which branch you are talking about. As the versions are released you can slap a Major.Minor.Revision stamp on them, but until then you need to name them in a way that will be recognizable.
Split them into branches and sub-branches.
Make sure that anything dependant on a higher branch has a derivative name.
So, you could call a branch ProductionMac, and a branch ProductionWindows, and that way you would know instantly that they are not to be merged, and that they both derive from production.
The most important thing to maintain is the structural hierarchy. Version numbers do this fairly well, but you have to keep adding "." for each new layer, which is annoying and completely undescriptive (much like naming your variables variableOne,variableTwo,variableThree) So, make sure that however you choose to label each branch, it is still obvious which branches are related to which other branches.
Sounds like numbers aren't going to help much, I'd go with naming the releases after small furry animals.
Or, name each release after the project that spawned it ('UI overhaul', 'June maintenance' etc), and then only assign it a version number when it goes live?
I'd use a dictionary to map between internal development numbers and external "release" numbers, then use the internal development numbers internally and only expose the "release" numbers when you're ready to release it out of development.
Bonus points if you use an intermediate map using irrational numbers. "How is development on release 3.14159 going?" "Oh, not bad, but I'm still fixing a bug we found in release 2.71828183." "What? That bug? That was supposed to be fixed with minor release 1.73205!" :-)
As others have suggested, use a non-numeric codename internally, and apply a number as each component is released.
Appending a revision/build number to your versioning can help you match this internal codename to the external version number (and can aid in communication with QA).
For example:
RegulationCompliance r1234 corresponds to the release 1.1.0.1234.
Based on what you describe, I agree with the first couple of posts. Meaningful, unique names relevant to the scope/feature-set are probably the way to go for each branch. Numbered versions seem reasonable within each named branch.
What you really need... is Gmail-style labeling... for your versioning!
nth-ing the previous posts.
We have our build system increment the build # after each build (whether or not it is to be released) which is what dev/QA uses to identify builds. The final version # is ONLY exposed to the outside world when QA releases. So there are really multiple builds of 1.3.0.x, but only one true 1.3.0.
Here is another alternative I considered while churning on this yesterday. Perhaps I need to rethink what is considered major. Integrating with another system may be a small quantity of work, but if it impacts the scheduling and release dates and version in such a significant way, as it does for me here, maybe that alone is a large enough impact to bump the branch up to major status. Then some of my headache would be minimized.
The most likely scenarios for releasing versions out of order revolve around the minor iterations. The major ones take a coordinated, cross-departmental effort. You can see them on the horizon. The minor ones sneak up on you and fork everything up.
"Here are the new compliance
regulations. If they don't go live by
July 15th, we will be fined $500,000.
Per day."
"What? When did you get these?"
"Last July. Weren't you CC'd on the
distribution?"
** facepalm **
I still think Devinb's answer is best. But I wanted to throw this out here for others in this dilemma.
peace|dewde