I would like to use a Java library (SpringBoot) in latest version (2.0.0.M6), but I prefer to use only releases. So what means this "M6" in the library version? Is it a pre-release?
Thanks!
It is a Milestone release. The version includes some set of functionality that were released as soon as that set of functionality was complete.
In some organizations, this is considered pre-alpha software, where an alpha release is the first phase to start white-box, and possibly black-box or grey-box testing techniques.
Since these milestones have a number associated with it, this is the sixth milestone. What that means is entirely dependent on the project, and its development / release plan.
For spring-boot specifically, they targeted the completion of these issues to state that they had "achieved" 2.0.0, Milestone 6.
https://github.com/spring-projects/spring-boot/milestone/92?closed=1
In any case, this is pre-release software.
Related
Can anybody please explain what is the meaning of PRE, SNAPSHOTS, GA and Current for spring-boot versions?
Below is a screenshot of versions shown on spring-boot website.
Also, latest version contains M3 appended in end just before PRE.
Please help!
GA
GA as in general availability are versions that have been released to the public. A version that has had this status for once will never change its contents.
CURRENT
The most recent GA release that should usually be used for all new projects.
PRE
pre release versions will also not change but are only released to let developers test the features of an upcoming GA release. They might contain some bugs that will be fixed in a later pre release of the same version (i.e. bugs in 2.0.0 M1 will probably be fixed in 2.0.0 M2). M is short for milestone.
SNAPSHOT
Same as PRE but this version is usually built every night to include the most recent changes. See this question on more about snapshots. Might also contain bugs.
Version life cycle
The usual life cycle of a single version would be as follows on the example of version 1.0.0:
1.0.0 SNAPSHOT those releases are built every day, replacing earlier snapshots of the same version
1.0.0 M1 once a development milestone was reached a single build is made that is called M#. For the next milestone # is increased by one. Milestones are never overwritten. Snapshots are continued to be made every day.
1.0.0 GA once the last milestone was released and the latest snapshot is feature complete and all known bugs are fixed the general availability release is made. From there on no other Releases of the same version are made, i.e. no more snapshots or milestones.
If bugs are found in a GA release the last version number is increased by one (i.e. 1.0.0 to 1.0.1 and a new release cycle is being started).
Is it best practice to develop and deploy on the EXACT same JRE/JDK versions (assuming you can control both ends)? Say you are running JDK 7_45 in production but have 7_51 you your development box. Is that potentially problematic - in your experience? I'm guessing the best practice would be to have them match but just wondering how problematic it could be assuming you are at least using the same major release. I suppose this also goes towards backward compatibility of JVM minor release versions. In the typical user space, I could be running Java apps built over time using many different Java development version JVMs yet all 'should' be expected to run on any JVM version. Would have to 'expect' that since I cannot obviously control the user's installations. My question is more related to the fact that I AM able to control both ends (dev and prod) so would it be wise to use the same JVM/JDK versions? Seems like the obvious answer is YES - use the same versions - if you can.
Generally, developers tend to have the latest version of the JRE/JDK installed on their development environments (Windows/Linux/OSX). This is fine, as long as you ensure that the program will run on older versions as well. So, you can develop on one version and use different version on production, as long as you extensively bug test with the older version to allow for backwards compatibility, or specifically state you are requiring a newer version of Java than is available on the user's system.
I remember issue then I could not perform build with old version 0.7 of Gradle when my colleague was using 0.8...
So was Gradle syntax frozen with version 1.0?
I didn't find such statement in release note...
The 1.x series will see major new features (for example parallel build execution) while at the same time retaining backwards compatibility with 1.0. Once we make the jump to 2.x (which we don't plan to do anytime soon), certain 1.x versions will still be supported for an extended period of time (long-term support model).
It has no evidence. I didn't see any information about frozen api
I've read the HornetQ FAQ, but I can't find anything related.
I'm using HornetQ 2.2.5, it contains a bug (yeah, just one ;). According to this post https://community.jboss.org/message/624958?tstart=2 it's been fixed from 2.2.7.Final onward.
On the main download page, http://www.jboss.org/hornetq/downloads the latest version available is 2.2.5.Final. I'm not scared of compiling a newer version myself, but can I consider it stable?
I'd say yes since it's a minor release update, but I'd like some other opinions. Thanks.
This answer uses the 2.3.X branch as an example. Let's skip looking at their Downloads page, and go straight to the artifacts:
http://mvnrepository.com/artifact/org.hornetq/hornetq-pom
You can see that 2.3.X went through Alpha, Beta and CR stages, to finally reach 2.3.0.Final, the Community release. This is what most people in the open source world would end up using, and what you will find available for easy download.
It's also the last version the non-paying customers are intended to use (in the typical JBoss release cycle - see e.g. the JBoss AS/EAP FAQ). Now, from a commerical perspective, 2.3.0.Final would be considered Alpha again. An analogy from the JBoss AS/EAP FAQ which probably applies here too: "The first EAP stage Alpha is of equivalent, or better, quality to a community Final release [...] we don't recommend using it in production" (probably an overly harsh judgement, but anyway.)
After 2.3.0.Final, they fix more bugs (2.3.1.Final, 2.3.2.Final, ...) until they get to a commercial production release (which they bundle into their other commercial products). So, you should be using the latest .Final that you can for production (for the 2.3.X branch, it was 2.3.13.Final).
Do you have to pay for 2.3.13.Final? From what I can tell, you don't. (HornetQ is also not available commercially AFAICT, except when bundled into other products.)
How do you get 2.3.13.Final? You probably won't find a nicely packaged RPM or even zip file. Instead, you will need to get the JARs from public Maven repos (or build from source).
Do you need a postgrad degree in JBoss Versioning and Product Naming to use their products? Perhaps :) - I don't have one, so apologies in advance if I have failed to comprehend the enormous complexity of the beast. But I do wish the HornetQ developers would make it easy to get a stable release of their product, and know that this is what one is using. It's a good product (perhaps the most fully featured of the lot), with an excellent manual, but a snap judgement of the download page and FAQ may make some people look at competing projects instead.
Well, after some more research, I can say yes, it is stable.
In particular, JBoss EAP 5.1.2 package includes HornetQ version 2.2.10.GA.
I wonder why there is no direct link on the HornetQ download page.
Since upgrading to Eclipse 3.7, the Eclipse PDE plugin wants me to specify an 'API Baseline' for all my Eclipse Plugin projects.
However there seems to be no documentation which actually explains what 'API Baseline' stands for here, and what is it used for.
Could somebody please explain?
API Baseline are intended to help you maintain plugins that others can use. The API Tools help you create compatible API versions. Follow the link that Sumit Singh posted to get an explanation on how to use them.
The Problem:
You create your plugin and release version 1 to the public.
Millions of people will use your plugin and create their own code that depends on the API of your plugin.
You release version 2 to the public. By mistake you change the API of your plugin.
Millions of people update to the new version and have to adapt their code. Thousands of programs fail. People are sad.
The Solution:
You create your plugin, annotate its API and release version 1 to the public.
Millions of people will use your plugin and create their own code that depends on the API of your plugin.
You declare version 1 of your plugin to be the API-Baseline that your code changes are automatically compared against. Any break in the API is presented to you before you release your plugin or run your tests. You release version 2 without any API changes.
Millions of people can update your plugin in their application, because the new plugin release is binary compatible to the previous one.
You declare version 2 of your plugin ....
Summary
If you develop a plugin just for your personal use and are not interested to maintain a compatible API, you can follow the advices to disable the warnings.
When you develop plugins for a community, e. g. the eclipse plugins themselves, it is essential that you keep API incompatibilities to a minimum. Then you will follow the advice and set the baseline to 4.2 when you develop for 4.3. The API tools will help you make 4.3 an enjoyment for all current 4.2 users.
Please note, that the API Tools are for the developers of the plugins that will be used by others. They are not addressed at the users of those plugins.
From the PDE API Tools User Guide:
An API baseline defines the state you want to compare your development workspace bundles against for the purposes of binary compatibility, bundle version numbers, and #since tags. For example, if you are developing bundles for Eclipse 3.4, you will use Eclipse 3.3 as your baseline.