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
Related
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.
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.
Normally all our upgrades, feature or bug-fix, are incremental. This seems obvious because even to develop a bug-fix we take the latest code-base of our product. However, this leads to a requirement that our customers have to update the software to the latest version even to get a bug-fix, they get the features as well as bug-fixes.
Recently, customers are telling us that they want the ability to get bug-fix patches without having to use new feature enhancements. Basically they want the bug to be fixed but they don't want new features. This is a dilemma for us. This is possible if the bug-fix changes a different set of binaries than the features. However, many times the features and bug-fixes are in the same binaries.
Is it even possible to create an upgrade that can be applied on any software version independently? Do others do this? Are Microsoft or Office KB patches ever non-incremental? Any guidance or links to relevant articles are highly appreciated. Thank you.
What the customer wants is normal but that does not mean that this is an easy problem.
What you describe is at the heart of configuration management. SCM is not just using a tool like git, it is using such a tool to solve the needs present. There is no silver bullet, to meet configuration requests take a lot of work and preparation of your code. I see that you have not tagged this as configuration management; this is exactly what you need to research if you have not.
Back to your specific request: The customer wants to be able to release bug fixes without the features you are continually working on. For the purposes of this answer I will assume your business model is that you offer a product which is a living thing and that several customers 'subscribe' to.
Branching strategy based on customer
Customer X, Y, and Z all gets different branches. Along with a developing branch from which you can pull features/bug fixes to the customers that want them.
This solution I would say is often very challenging (SCM generally is), you have to deal with diverging codebases and the developers have to be very aware of your work-flow.
Release branches
Having a branch for every released version which you can patch with bug fixes while not bringing in the new features is what I suggest. You're question is a bit unclear what you mean by incremental, if this somehow refer to the distribution of the patches itself then that is another matter and this answer will be less useful.
Feature-flags
You deliver new features to the customer which do not want them but they are hidden behind logic in your application. This can be hard to combine with what you describe as 'complete revamp'. This can also have other advantages as it makes it easy to perform A-B testing.
It places requirements on your architecture and also discipline when it comes to what to allow, too many feature flags for every little thing and it can get un-maintainable.
Have a strategy
You need to plan for this or you can not satisfy your customers needs. And it may be very well that if you have customers who wants the wrong things you have to negotiate. But providing bug-fixes without new features I think is the minimum
The books I read on this is old, but here is one i remember anyway: Wayne A Babich: Software Configuration Management - Coordination for Team Productivity
Release Strategies on the Rene Moser blog may be helpful.
The LTS (Long Time Supported Versions) section seems applicable to your concerns.
Regarding your questions:
Is it even possible to create an upgrade that can be applied on any
software version independently? - Sure, but it takes extra time, effort and money (usually).
Do others do this? - Yes.
Are Microsoft or Office KB patches ever non-incremental? - Yes, for major releases; but not KB patches.
A follow up question: is it worthwhile to do the extra work to facilitate non-incremental software releases for your software users?
The answer to this questions depends on your customer base, which may require a long meeting with the software developers and those in Marketing. If the customers wanting non-incremental releases are significant in terms of their numbers and revenue, then the extra work is probably necessary to keep those customers.
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
We are in the process of selecting a workflow solution for a company that uses Microsoft products end to end. Given the news on WF4, in that it seems to be essentially a rewrite of previous versions, is it a wise move to back the current version or should we be looking elsewhere?
Ie - is the current version so bad that we would not be wise to try and use it?
Haiving just launched a project which .NET 3.5 and workflow I'd say that the current release of WF is good enough to use and run with. It has helped us to get a product out quickly (we have the usual feature creep and requirements changing weekly). However, I have a list of complaints with it:
The workflow designer will drive you insane because it is so slow (in certain circumstances) and re-arranges your state machines as it sees fit.
There is no built in upgrade strategy for keeping your old workflows running once you do a bug fix release. If you are going to use WF think carefully how to do upgrades early.
Itegrating with WCF (the send and recieve activity) hide the WorkflowRuntime from you this makes it very difficult to understand what is going on on the hood.
Its not easy to unit test them. There are ideas out there but none seemed particulary easy when we started this WorkFlow Unit Testing
I like the ideas and potential of Workflow based development, however I am not in a hurry to repeat this experience and would probably stick without it for long running processes. One place I would use it again would be in a short, complicated process (like a rules engine for working out prices).
Maybe it is a little late for you, but now that WF 4.0 is released in beta, other people thinking the same question can consider backing the 4.0 horse instead of 3.5 horse.
This goes some way to fixing the following problems:
•The workflow designer will drive you insane because it is so slow (in certain circumstances) and re-arranges your state machines as it sees fit.
[Designer Perf Improved]
•Its not easy to unit test them. There are ideas out there but none seemed particulary easy when we started this WorkFlow Unit Testing
[I think it's a little easier now, some of the introduction to workflow samples include plenty of unit testing]
My understanding is that Microsoft will provide backwards compatibility and/or a migration strategy to the new WF, so I would guess that you are safe to use it. However, I have heard from other developers in my organization that the current version of WF is extremely painful to use. If you have the budget (and depending on the complexity of your workflows), you may want to consider K2: http://www.k2.com/en/index.aspx
I, as a workflow developer, think that current version is painful to use. This is not surprising as this is a v1.0 software out from microsoft :)
I think you should first consider your expectations from a workflow software. Do you have a well defined list of expectations from WF? Acutally I am wondering content of such a list. Maybe we can help more detailed on each topic.
I don't know why people have such negative impressions about WF. Sure it has it drawbacks, but I thought it was pretty useful. The one major issue I have about it is the lack of support for upgrading existing workflow (bullent #2 in gbanfill's list).
Another point to use the current version is that "Dublin" (Microsoft new App Server) will be built on WCF & WF .NET 4.0 but will gladly host 3.5 WF's. So you will be able to migrate to that without a rewrite.
Just a quick note to mention that Visual Studio 2010 CTP contains a new updated WF designer as part of the Oslo objective.