What are the extra feature added to open daylight stable/beryllium version?
And what are the architectural changes between Open daylight helium and Open daylight beryllium?
Helium and Beryllium are two major releases, and there was Lithium released in between. If your question is whether to go ahead with Beryllium or Helium, definitely go with Beryllium. Almost the entire architecture changed - with Karaf based deployments and the move to MD-SAL from AD-SAL.
Have a look at https://www.opendaylight.org/odlbe Note that this is comparing with Lithium. Helium is an older version. So have more changes, obviously.
Related
I've been bitten by a strange (IMO) behaviour in TFS today. This is the third time I've seen this in the three years I've been using TFS. It's best explained with an illustration...
I have an In-progress branch of a webforms project, that is used for quick bug fixes and small changes. From that, I do a branch for larger development projects.
Last week a customer reported a bug on Page123.aspx. We did a branch, fixed the bug, and merged Bug fix branch back to In-Progress branch. All changes were committed at each stage.
This week we deployed to the live system from In-Progress, only the see the bug had mysteriously come back.
At no point on the In-progress branch was Page123.aspx modified. When I compared local/server versions, the server version had the fixed page, and the local version was still buggy. However, I am the only developer, so I don't understand how this could happen.
When I branched again from In-Progress to New dev branch, the buggy Page123.aspx obviously remained.
The only way to force my TFS/VS2013 to remember the fix was to do a Get Specific Version on Page123.aspx to replace the local version with the server version.
Is there some kind of bug in TFS that causes this, or is it stupidity? 99% of the time merging correctly gets the latest version of every page.
I expect this is a common issue, but one I am not aware of a sensible solution to.
We have adopted the procedure where all local dependent modules are moved straight back to SNAPSHOT once the release has been done. Time passes and we come to do a new release.
When we come to release we need to make a decision on whether a particular module has had any changes or not. If not, we dont need to update release the dependent snapshot and we can simply build against the previous release version as nothing has changed.
The difficulty in this process is establishing whether anything has actually changed since the last release or not. The only way I can imagine establishing this is to look in the subversion logs to see if any significant change has been checked in since the last release, and if it has then we need to release the dependent module. If it hasnt, we are ok to use the previous released version. This seems very labour intensive to me.
Is there a plugin or a better way to achieve this?
Let's suppose I have a project called myLib-1.1.0. This project has a dependency on lib-dependency-1.2.3.
If there's a new version for this dependency and I need to use it, should I change my project version as well? No other modifications are made to myLib.
At the same time myLib is a dependency for various other projects. My main concern is the impact of a small change in a dependency might have upstream.
Yes. In maven, released versions are immutable. If you release 1.1.0 with a dependency to lib-dependency-1.2.3 then that's it.
If you change to depend on lib-dependency-1.2.4 then that's a new version. You should not redeploy 1.1.0 since some people might have already pulled that (supposedly immutable) 1.1.0.
So that means you need a different version, even if it's a just a new qualifier (myLib-1.1.0-RC-2 for example, but better just 1.1.1)
Maven doesn't recheck remote repos for release versions once it has it in the local repo, so if someone has 1.1.0 already locally, they will not get the new, fixed 1.1.0.
And about your rippling problem. Upstream projects should depend on the lowest acceptable released version. i.e. if the upstream project itself is ok with myLib-1.1.0 because it doesn't need (indirectly) lib-dependency-1.2.4 then it should stay with 1.1.0
Any code change that potentially affects the behavior should be given a new version number, in other words: anything that's not an absolute trivial change should be given a new version number. A changed dependency would definitely qualify for that because, unless you do a thorough code inspection of the dependency, you have no reason to assume that they only made absolute trivial changes.
Changes are often advertised as "small" (similar to being absolutely trivial as I call it above), but they hardly ever are. They may be negligible in someone's use case, but not in someone else's use case. I've even seen circumstances where there were only changes to Javadocs in a project that would break things down the line. (You could argue about how smart it is for someone to depend that strongly on Javadoc, but that's besides the point, isn't it?)
That is not to say that you can't accumulate changes and release a bunch of them as a single release. While accumulating, your project is in flux, and should have a ...-SNAPSHOT version. There should be no two versions of myLib-1.1.0 (without the -SNAPSHOT) that have even the least little change.
The fact that you're re-releasing your project also makes explicit the fact that regression testing and such should be redone to validate that it's still working with the changes in its dependency.
http://www.springsource.org/downloads/sts-ggts
I am trying to download new STS tool. On the above site I find
Milestone Version and Release Version. Can anyone tell me what these terms mean? Which is Users version to be used and is completely developed and not under-development?
The release version is the one you want, "release" means it's considered to be done and ready for the public. "Milestone" means it's a stable checkpoint made available for community developers to test. You'd pick the milestone one if there are new features or bugfixes you want to try out that haven't been included in a release yet.
I have a theoritical question : I have a project that has versions, for example :
0.1 : alpha
1.0 : first release
2.0 : breaking changes
And I have a task management system (Redmine, but it's the same for trac or anything else...).
In which version do I put the task that will make the application work (currently it doesn't work) ? Is that in 0.1 (once 0.1 is finished, then 1.0 works) or is that in 1.0 (once 1.0 is finished, then 1.0 works).
Another way to ask is : Is a task of version 1.0 a task that helps making the 1.0 version, or a task that extends/fixes the fully working 1.0 version.
I am confused, because a task can
precede the release of a version (i.e. working on the release)
follow the release of a version (i.e. the release is out, we need to fix bugs and extend it)
So which tasks do I put in a version ?
I don't know how to manage tasks and versions, can you help me ! How does it works in Open Source coding ?
Thank you !
PS : please let me know if that is not clear enough
You need to separate tasks and versions in your mind before you can come back and apply them.
Tasks are work you do on your code.
Versions (and I'm lumping in all point releases here) are releases of your code.
You to work, tasks, on your code with the objective of making a release. That release, depending on the scope of the work you are doing may be a full version 1.x.x, 2.x.x, etc., or a point release 1.1.x, 1.2.x, 1.3.x or it may be a minor point release/bugfix/whatever you want to call it, 1.0.1, 1.0.2, 1.0.3.
The tasks could be bug fixes, features, changes, refactoring, whatever. In the scope of a full application development you may that your organisation bundles groups of tasks in to the work needed to make the next release or you may have releases date-bound, i.e. you'll release version 2.0.0 on 25-Feb-2011 regardless of the tasks completed (although normally there's a subset that must be complete for the release to happen).
Version releases tend to follow major updates, upgrades, feature additions.
Point releases tend to follow moderate improvements, and major bug fixing.
Minor point releases to be the result of bug fixes.
Every where you turn you will find different approaches to this process and you just need to either understand that used by your company or if you have the opportunity, to find one that makes sense to you and then apply it consistently.