I'm a little bit confused. I know that sugarCRM no longer supports version 6.5 as of 2016, but there are still security patches being applied in 2017 as per
http://support.sugarcrm.com/Resources/Security/sugarcrm-sa-2017-005/
Does this mean that no new functionalities will be added but security patches and bug fixes will still be applied?
Support vs maintenance
As per Clint's thread: https://community.sugarcrm.com/thread/18434
We are expecting to support and issue maintenance releases to v6.5
through summer 2015 when v6.5 hits it end-of-support period.
So I'm assuming that support for 6.5 ended in 2016, but on this page http://support.sugarcrm.com/Resources/Security/sugarcrm-sa-2017-005/ we see the mention:
The list of affected products reflect all currently maintained
versions at the publication date of this advisory.
Which is a bit confusing.
Thank you
As per Sugar support. So it's no longer supported in any way shape or form it seems
6.5 is no longer supported and no additional patches of any kind (including security) are being developed. End of life for 6.5 was
reached in July 2017. Our current supported versions list can be found
here: http://support.sugarcrm.com/Resources/Supported_Versions/. This
blog post may also be helpful to read, especially if you're using CE:
Sugar Community Edition open source project ends.
Related
Can someone tell me why the SAPUI5 version "1.56.16" stopped working? (using CDN).
I know they have been removing some outdated versions, but, I don't see this one on the list.
Or maybe I don't understand which ones are getting removed...
Versions List
Thank you!
You actually answered your question yourself: You can find this information on the SAPUI5 Version Overview Page.
If you check there table SAPUI5 Versions Maintenance Status you can see that 1.56 is an interim version as it never had long term maintenance. So this means this version went out of maintenance when 1.58 was available or rather in case of consumption via FES when 1.60 was available (which was around Q1/2018).
In column End of Cloud Provisioning you can see that the removal of 1.56 was scheduled for Q1/2022. That's why also 1.56.6 is not available anymore.
The schedule when a patch will be removed can be found below in table Available SAPUI5 Versions on SAP Business Technology Platform, but only as long as they are available. As a rule of thumb patches will be removed if they are older than one year or rather with the End of Cloud Provisioning of the respective SAPUI5 version.
It is important to understand that the removal of outdated SAPUI5 versions will happen at regular intervals, each and every time when a patch is older than one year or rather a version is out of maintenance for one year.
Very little has changed in a while for BIRT. Since the project seems still heavily used, it would be interesting to know if there are future plans and if so, what is entailed in those plans. Subsequently, based on the development status: Is BIRT still a safe platform to base development on or is it expected to just be conserved in the current state such that occuring bugs probably won't get fixed?
We decided to use BIRT instead of Jasper 8 years ago.
We are still using 4.2.1 for development and 4.3.0 for production runtime.
I reported several bugs since then and only very few of them got fixed.
Furthermore, I developed some patches to enhance the word emitter output - with no reaction from any one at all.
I also developed a patch to allow kind of a vertical tab (to place something at a fix y position on the page (but not in the page footer). With my previous experience of the community, I did not publish that one.
I can say that while the source code is quite easy to read, it is nevertheless almost impossible to understand what is actually going on, because the functions are extremely deeply nested.
My conclusion with 8 years experience of using BIRT for production:
PROS:
BIRT is very powerful and flexible, you can achieve some very cool results.
The quality of the resulting PDFs.
There are only very few things I miss and cannot work around.
The runtime engine is very stable and fast enough, very few problems.
The community is helpful.
CONS:
From an open-source perspective, it is one of the weakest projects I know of.
New versions tend to introduce more bugs than they fix.
Bugs, ideas and patches from the community seem to be ignored most of the time.
Lack of internal code quality and documentation.
Update Dec 2021:
BIRT is back again!
The open source project is quite busy (see answer by Alexander Fedorov) and every help is welcome.
It looks like there will be a new release soon.
Until then, building BIRT yourself (with Eclipse 2021-09 and Java 11) has become quite easy thanks to the common effort of the community.
Metadata and information about the health of an Eclipse project can be found on projects.eclipse.org:
The Birt project is still alive, but not as active as before:
there has been only one release per year since 2016 and
in the last three months there have been more than 20 commits from 11 contributors.
Like all open source projects, the success of the project depends on participation. Therefore, I encourage everybody to report bugs and propose changes to Birt and other open source projects.
Update: Good news, Eclipse Birt has been rebooted. It is under active development again, there have been more than 100 commits in two and a half months and the release 4.9.0 is scheduled for March 16, 2022.
The Eclipse BIRT project has been restarted recently, and we are working to prepare Eclipse BIRT 4.9 release.
Contributors are very welcome. Here is the brief instruction regarding steps how to join this effort: https://eclipse.github.io/birt-website/docs/community
Latest versions of BIRT are not available in maven.
I wonder what the meaning of NuGet is. Is it something like blah blah get? Does it even have a meaningful name? Or is it an abbreviation of something or somebody decided that name for fun? Please help, that question has been eating my head for 1 week.
Look here.
Seems it was voted on.
It's a bit hard to say (maybe I didn't look into it well enough) but -- especially since pronunciation is "New Get" -- basically:
NuGet: A new way to get libraries.
Nu stands for -> "Nubular / Nu". Around mid-2010 Dru Sellers and gang (including Rob Reynolds aka #ferventcoder) built the fantastic “nu[bular]” project; this was itself a ruby gem. Team Nubular developed.
In October 2006 Nu became Nu v2, at which point it became NuPack; The Epic Trinity of Microsoft awesomeness – namely Scott Guthrie, Scott Hanselman, and Phil Haack – together with Dave Ebbo and David Fowler and the Nubular team took a mere matter of months to create the first fully open sourced project that was central to an MS product – i.e., VisualStudio which was accepted into the ASP.Net open source gallery in Oct 2006
It’s referred to as NuPack in the ASP.MVC 3 Beta release notes from Oct 6 2010 but underwent a name change due to a conflict with an existing product, NUPACK from Caltech.
NuGet! (finally)
There was a vote, and if you look through the issues listed against the project in codeplex you can see some of the other suggestions.
(Notice how none of the names available in the original vote are “NuGet”..)
Finally we have NuGet! The associated codeplex work item actually originally proposed “Nugget”, but that was change to NuGet.
Here's the link- https://www.robinosborne.co.uk/tag/nupack/
Ubuntu is usually a cutting edge distro. But why does it stick to a 2011 version of Eclipse when we are 4 years into 4.x development?
It's not even optional and cannot be installed from the repositories. And it's not 'easy' from a download either. For some reason, the Java SE 7 reference implementation, OpenJDK, is not enough, and you need the Oracle version. Why? This isn't available from the repo's either, and you need some weird untrusted 3rd party repo for that or follow a whole chapter on how to install it yourself.
There were problems three years ago. When Juno 4.2 came out, it had a lot of performance issues. Eclipse Director Mike Milinkovich explains one of the reasons is lack of funding. For the first time in a major release:
"The performance test were turned off because the Eclipse platform team has a serious resource issue."
For that reason, developers released unnamed and unpromoted version 3.8 simultaneously with 4.2 to bridge the gap for this (hopefully) temporary problem, and it's popularity caused a notable trend downwards amongst developers. As one Eclipse b3 developer mentioned:
"I was stunned by the performance improvement after the switch. The 3.8 platform is much MUCH faster"
The 3.8 release is still a popular alternative to the 4.x branch among developers (ask my colleagues or google), I think mainly because of (genuine) trust issues. But the bridge (read: support for 3.8) has closed now that 4.3 is released.
The core problems (funding and developers) have not been fixed though, as seen by Google's gesture of donating money to the Eclipse Foundation in the hopes that other companies will follow suit. Does this mean that 4.3 is still not up to par with the 3.x standards?
This is not a problem with a plugin or a feature for a specific language, this is a problem within the core of the platform itself. (But I'm using WST with Javascript and V8 plugins for PHP and Node development in particular.)
This is not a specific platform problem either. There are similar complaints from Linux, Windows, and OSX users. (But I'm using Linux (Mint 13).)
On the one hand you have people telling the EOL for 3.8 "proves" that 4.3 is fine now. On the other hand (see comments):
"I've moved back to 3.8 due to constant crashes on ubuntu with 4.3"
3.8 is far from problem-free and I wouldn't mind to get a smoother development experience. So I am wondering, why is Eclipse 4 'kept from us' by the people who decide what software versions are 'good for us' (AKA what goes into the official repository)?
lucid (10.04 LTS)
Eclipse 3.5.2-2
precise (12.04 LTS)
Eclipse 3.7.2-1
raring (13.04)
Eclipse 3.8.1-1
saucy (13.10)
Eclipse 3.8.1-4
trusty (14.04 LTS)
Eclipse 3.8.1-5.1
utopic (14.10)
Eclipse 3.8.1-5.1
Update 2014-05-30: I just tried Kepler (again) and it still suffers from UI glitches out of the box. E.g.:
And no, changing the inactive window toolbar background color in preferences does not fix this. (Even if it would, this would be a silly default choice).
I would like to know, from someone who is not positively or negatively biased because of their own highly specialized and tweaked workflow - preferably from someone with experience in the Ubuntu package maintaining process for non-trivial packages - why this decision is made by a team of professionals who know what they are doing for the most widely used Linux distribution out there?
Eclipse Juno was released 2012-06-27. On 2012-07-17 a bug concerning the responsiveness of the UI was reported. Four months later, around 2012-11-14 the first patch was released to the official update-site.
Many users, however, completely missed the release of the patches. I assume the information drowned in the FUD, and other more important news, that was spread around that time. At the end of 2012 I posted an answer on SO. Apparently I was not the only one for whom the patch fixed this performance issue.
On 2013-02-22 Eclipse 4.2.2 was released, which contained the same patch, yet I kept receiving upvotes for my answer on SO until June.
Probably the only known fact among developers is that Eclipse had serious performance issues at some point. However, the knowledge about scope, magnitude and duration of these issues seems to me like a series of common misconceptions.
There was a four months period during which it was a good idea for many Eclipse users to stick with the 3.8 branch. I say "many" because I worked with 4.2.0 and 4.2.1 and it was O.K. for me. Subjectively, switching tabs was about two times slower and the IDE froze maybe once a day for a couple of seconds. For colleagues of mine the problem was much more severe. I assume it depended on your setup and on your workflow, however, I never felt like investigating further because I knew the platform developers were working on the issues, and there was a good fallback, using 3.8.
One year and three Eclpse releases later these serious performance issues are still fixed.
Of course, this doesn't mean that there are no more performance issues. As of now I find 1979 reports in the Eclipse bugzilla with the keyword "performance". This doesn't mean that Eclipse is very buggy, but only that it is very well documented and open. Whether or not you are affected by any of these issues, again, depends on the setup, the plug-ins you are using and your workflow. I am a Java, plug-in and EMF developer. I work with medium to big work spaces (~1M LoC), and Eclipse 4.3.1 is fast enough. The 3.8 release is not an option for me because as Eric said, it won't receive all of the important updates. People will still continue using it in the future. Many of them will also continue using Internet Explorer 5.5.
If you try the 4.x branch and notice any performance issues, please report them, but be specific about your setup.
From the official Wiki page:
Several major performance defects have been addressed in Juno SR2
(4.2.2). Community members have confirmed that these fixes
substantially address the performance problems with editor and view
opening, closing, and switching. These fixes are widely available in
Juno Service Release 2 (February 2013). All defects are also resolved
in the Kepler (June 2013) release stream.
new Features
Your statement "3.8 release was specifically released as a faster and more stable alternative to 4.2" is clearly incorrect; 3.x has gone into its 'end of life' maintenance and was most certainly not released as an alternative to 4.x.
While folks are welcome to continue to use the 3.x stream if it suits their needs please recognize that as the various projects move forward there will be significant divergence in the features available between the two versions...
Based on the commit history, it looks like protovis has not been touched since August 2010. Has the project been abandoned?
http://gitorious.org/protovis/protovis/commits/master
I'm evaluating javascript charting libraries for my company and would hesitate to recommend one that is no longer being developed.
Protovis is no longer being actively developed; instead, it has been reincarnated as D3.js:
http://mbostock.github.com/d3/
There is an introduction for Protovis users that elaborates on the major differences, and why we decided to develop a new library rather than make incremental improvements.