I keep hearing about Symfony 3, in particular the new directory structure, but I can find nothing about a release date. Are there plans to release a new major iteration of symfony?
Yes there are plans but nothing definite yet.
The community section of the Symfony 2 site has plenty of information on these sorts of things.
From: http://symfony.com/doc/current/contributing/community/releases.html
The work on a new major version of Symfony starts whenever enough
major features breaking backward compatibility are waiting on the todo-list.
The next major version will be 3.0.
The next major long term release will be S2.7 schedule for May of 2015. I would not be surprised if serious work on S3.0 starts after that release but that is just a guess. Check the development mailing list and chat rooms for more information.
Related
I have been reading a while on the subject and I came across an article which left me a little bit lost on software versioning/releases.
If you follow it you will see it's just a list of all Symfony releases with their respective dates. What prompted me to ask this question was the fact that I could not get why/how, for example:
Symfony 2.8.37 released | April 2, 2018
while
Symfony 4.0.6 released | March 5, 2018
Symfony is just the example, my question applies to software versioning in general looking for an explanation to the above.
I am (am I?) positive that 2.8.37 is older than 4.0.6 so this most certainly has nothing to do with me comparing them wrong, surely there is a fundamental aspect about the versions release process I'm unaware of.
Finally, just to be sure, if I were to compare two versions, how would I go about it, I don't need a computer-language-specific-solution, just an algorithm in general to compare two given versions like you could do even using paper and pencil (I know, what a heathen).
Typically, 2.8.38 would be a security or other patch to 2.8.37; and 4.0.6 is a patch to 4.0.5, where 4.0 is a newer, more powerful base version that requires a different license or runs only under Windows 10 or some other reason why some people would like to stay on the old version.
The patch to the current version would be published faster, and then the team adds the important security patch to the older versions.
Symfony has very good support for old versions of their framework. Basically Symfony 2 was released and went through various version changes similar to 2.1 -> 2.2 etc. All the while maintaining compatibility with previous Symfony 2 projects.
Further down the road Symfony 3 was released, and while a Symfony 2 project could be updated to a Symfony 3 project it involves some work and there can be project breaking coding changes required. Then Symfony 3 progress 3.1 -> 3.2 etc.
Just because Symfony 3 is out and available doesn't mean that all work or bug fixes are done on Symfony 2. So there will still be releases of Symfony 2, in addition to releases of Symfony 3. Here is a visual view from the Symfony Page to show the version overlaps.
This is common with most software, for example Microsoft Windows 10 is the current version but Microsoft still provides patches for Windows 7.
I am currently using Tinkerpop 2.5 in my application to represent a graph in-memory and gremlin to query it. This application will go into production at end of July 2015. I am confused if I should use 2.5 or 3. Currently Tinkerpop 3.0.0 is in M7 release. I don't see any information on the GA release schedule.
At this time, TinkerPop 2.x is basically in maintenance-mode only (i.e. we've generally frozen development short of major bug fixes). All effort is focused on TP3 and getting it to GA. GA has been somewhat delayed as TinkerPop moves to its new home as an Apache project: http://tinkerpop.incubator.apache.org/
Unfortunately, we can't provide much certainty for when GA will be available, so this leaves people starting a project and trying to make the choice between TP2 and TP3 a bit difficult. I can say that if you use TP2, it has good stability and a very wide number of vendors who support it. If you use TP3, expect some turmoil in the API on the way to GA and keep in mind that, at this time, you don't have a lot of vendor support for the interfaces though many vendors are committed to having TP3 implementations when GA is in place: http://www.tinkerpop.com/docs/3.0.0-SNAPSHOT/#_graph_vendors
UPDATE: TinkerPop 3.x was released into GA in July 2015 and can now be considered production-ready. There have been multiple releases since that initial one. Latest developments can be found on the project home page: http://tinkerpop.apache.org/
I rolled out JMock at our company, and many folks are using it with success. The version we are using is the latest stable release, which is 2.5.1. That was released in August 2008. Since then, two release candidates came out, 2.6.0RC1 and RC2 in 12/08 and 9/10, respectively. That seems like a long time for a release to be a "candidate." I'd like to update to 2.6.0, but my company is hesitant to use a product that is not a "stable" release. I share their concerns.
I have two questions about this. First, for anyone using the 2.6.0 RC1 or RC2 releases, have you found any evidence of instability in these versions?
Second, and this is more for the folks who created the tool, why is 2.6.0 considered still a release candidate and are there plans to release a "stable" 2.6.0?
Thanks!
Ken
2.6.0.RC2 seems to be perfectly stable. I'd have no issues with using that in anger.
I understand there are plans to push 2.6.0 to a full release, and that it's just a matter of free time to do it...
We're trying to get a release out but are short of maven help
I've come across the following excellent blogpost on a git workflow model that works with release, develop, feature and bugfix branches: http://nvie.com/posts/a-successful-git-branching-model/
It sounds like an excellent workflow and I am really eager to try it in production but one paragraph caught my attention and leaves me wondering.
It is exactly at the start of a release branch that the upcoming release gets assigned a version number—not any earlier. Up until that moment, the develop branch reflected changes for the “next release”, but it is unclear whether that “next release” will eventually become 0.3 or 1.0, until the release branch is started. That decision is made on the start of the release branch and is carried out by the project’s rules on version number bumping.
I'm wondering, how does this way of working reflect in your ticketing and bugtracking system? In JIRA and BugZilla we create "versions" that a ticket can belong to. Prior to switching to a release branch, what version does a ticket belong to when in the development branch? Do you have a version in your issuetracker for every branch?
And what about feature tickets that you know you are going to implement not in the upcoming release but in the release thereafter? Am I supposed to create a version "upcoming" and "future" for this kind of tickets?
Any insight in how this branching workflow reflects in ticket/issue management is appreciated!
Am I supposed to create a version "upcoming" and "future" for this kind of tickets
This is the basic idea. The key idea is that a current development will include some features part if the next release, and some which will ultimately be too complex and/or not ready in time and/or depending on other features which won't make it in said next release.
This is a bit like branches 'pu' and 'next' in the git repo itself.
In short, a feature ticket is rarely issued to a specific release number, while a bug fix ticket can be (2.1 for fixing release 2 for instance).
I did several websites with Drupal, and now the core is updated and I cannot come back to my customers to update previous installation. I was wondering how risky is to not update drupal core to the last version and how web developers should deal with websites management.
ps. My customers do not have any computer skills.
thanks
The openness of open source means that it is easy to know what an upgrade has fixed. It also means that a hacker could just look at the release notes and do a diff between the previous and current version to spot the vulnerabilities in the previous version.
If you have a good relationship with your clients I would explain the need for an upgrade and see if they want to pay you for it, as their sites are vulnerable to anyone determined enough to look at the release notes and do a little digging.
Here are release notes. Answer on your question lies inside.
Updating the core is very Important, it solves some security risks and brings new features.