The Node.js maintenance policy is described by the Node.js Long-term Support Working Group
I suppose that maintanence release will get lesser updates. But what are the exact differences between LTS and maintenance?
Answered by a Node.js Foundation Member
There are both Active + Maintenance LTS
The first 18 months are active, the last 12 are maintenance.
During active we try and backport as much as reasonably possible.
During Maintenance we only backport security fixes and major
unavoidable bug fixes
Source: https://github.com/nodejs/LTS/issues/76
Related
I have a Rails app which is a traditional web application (HTTP requests are processed and HTML pages are rendered). As of now, it does not have an APIs that are exposed to other apps.
I want to use semantic versioning for versioning the application. Currently it is at '0.0.0'.
Quoting from the documentation:
MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.
From what I understand, because there are no applications dependent on mine, the major version will never change. Only the minor and patch versions will change, the major version will always remain 0.
I want to know if my understanding is correct. Is there any scenario in which my major version will change?
Since you're not developing and releasing software package, semantic versioning is not directly applicable. It sounds like a single "release" number could be enough for your use case, since what you need is track when a code change will be in test and in prod. Assuming code must go through test before going to prod, you would update the number whenever you update the test environment with code from the development branch. This way, at a given moment development would have release N, test would have N-1, and prod N-2.
API versioning is a different problem, independent of release numbering. In my experience API users only care about breaking changes, so those need to be versioned. Also, since users are slow to update their apps you must be prepared to keep old versions around indefinitely.
One way you could think about this is to think about the user's flow through the application as the basis for versioning. If a breaking change happens (i.e. the user's flow is changed in a way that makes the old route impossible) then it could be considered breaking. If you're adding new functionality that hasn't existed before (i.e. the user has access to a new feature or sees something new on the website that they can interact with) then that could be considered a minor version increase. If you're deploying minor fixes to things like text, then that could be considered a patch-level change.
The problem with this approach, though, is that you need to understand a user's workflow through the application to be able to correctly increment the major version, and as software developers we're still pretty terrible at doing that properly.
Ref: https://christianlydemann.com/versioning-your-angular-app-automatically-with-standard-version
How necessary is an Expression Engine software update for an existing website that works fine? I have version EE 2.11.6 and have been advised to upgrade to version 4 --at great expense.
I need the site to work for maybe five more years before I retire my business. It is a simple brochure site for a photography business displaying pictures and text with a blog and a contact form. Nothing fancy, no sensitive customer data, nothing of interest to hackers.
If I don't do the upgrade, is it really likely to stop working anytime soon? Would upgrading to version 3 instead of 4 give me a few more years?
Thanks in advance!
Dennis
whether it will keep working largely depends on your hosting environment. If your hosting environment stays the same, you don't want new functionality (ie plugins), and you have no payment systems involved, you could probably make this site stretch another five years. On the other hand, if your host wants to upgrade operating systems and PHP versions, eventually EE 2 will not be an option.
An upgrade to EE 3 is a big jump from EE 2. The jump from EE 3 to 4 is not nearly as difficult. What creates the cost in upgrading is often incompatible plugins. The EE 3 release changed the underlying code framework to the point that many useful plugins were abandoned and many developers decided to exit the EE marketplace. Finding replacements and re-working the functionality the plugin got you can be time consuming and expensive.
By the way, every site has something of interest to hackers. Your content is not necessarily the end goal, if they can get access to your server through some exploit, they can then use it to send spam emails, host a botnet, or use the computing power for their own purpose with obscured traceability. That can bring negative consequences for your site in the form of blacklisting and other penalties for being hacked.
Best of luck!
We are planning to put our product on Azure marketplace. The product is installed on Windows server machines and is distributed in nature. The architecture that suits us the most is Iaas, however, we are concerned about keeping multiple versions and the upgrade policy. We normally release 2 versions of the software every year plus there could be more patches and service packs.
Please also note that our software doesn't have in-place upgrades. That means to upgrade our software, it is needed to be uninstalled and reinstalled.
We've googled to get some help but couldn't find any satisfactory answers. I'll appreciate if someone could. The questions we are really concerned about are;
How many versions can/should we keep on marketplace?
What should be the process to upgrade software on machines already running on Azure?
How to handle public patches and service packs?
Thanks.
I would like to know when Chrome's declarative web request API will be in the stable channel (https://developer.chrome.com/extensions/declarativeWebRequest). I realize that is asking a lot. I'd like to write an extension that depends on a beta API though and am just curious if there is a best approach for guessing when it might become stable.
declarativeWebRequest is not currently scheduled for promotion to stable. There were some issues with certain use cases that made the current design and implementation insufficient for the long-term support that stable would entail. We have not announced plans to proceed further with the API. You can star http://crbug.com/112155 for updates.
There is no way to guess when a Chrome API be become stable until it does. Priorities, features, bugs, etc make it impossible to predict.
i am about to develop a new application and I was looking at JXSE framework. It seems some political issues with oracle have killed the project from what i understand. this raises a few questions:
Is JXSE 2.7 stable enough for production use?
Will jXSE/JXTA for java still be developed?
is Chaupal the continuation of JXSE (does it start from the 2.7 codebase?)
when is Chaupal 1.0 set for release? (approximation i guess)
how similar will Chaupal interfaces be with JXSE (how easy will it be to migrate to)
thanks!
Political issues did not kill the project. Some people are still posting patches, but it surely slowed down involvement.
Is JXSE 2.7 stable enough for
production use?
Yes, some companies are even using the 2.6 branch.
Will jXSE/JXTA for java still be
developed?
Some people are posting patches on the 2.6.x branch and these will be re-integrated in trunk somewhere down the road. The future of JXTA depends on voluntary contributions.
is Chaupal the continuation of JXSE
(does it start from the 2.7 codebase?)
Yes and no. No, it does start from the 2.7 codebase, it starts from scratch. Yes, it is a continuation 'in spirit' of the development of an open source java based P2P library.
when is Chaupal 1.0 set for release?
(approximation i guess)
No plan for a date. We are working on our spare time. So it is not fast.
how similar will Chaupal interfaces be with JXSE (how easy will it be to migrate to)
Chaupal aims at being simpler and more straight forward. One of the weaknesses of JXTA was its complicated API. We want to solve this issue. We also want to focus more on communication between peers and drop the service loading features of JXTA.
Update (August 2013): You thought JXTA/JXSE was dead? Well someone worked further on it and developed a DZone tutorial (unfortunately, SO does not allow links to Dzone, so Google: JXSE and Equinox Tutorial).