When running a deployment in bamboo, it gives the option between 'promoting' a release or creating an old one. Is this just jargon for 'reuse' or is something else happening?
I've not found anything in the Atlassian docs, and only this came up:
You should create a new release if there were changes in your code since the last version. If you need to promote code from one environment to another, using the "Promote" feature is definitely the way to go.
I think that makes sense if you replace 'promote' with 'reuse' makes sense.
If you want to reuse some old releases, then you tell Bamboo promote(reuse) the previously built releases. In this sense, with promote Bamboo means reuse.
From Build Result you can always create new release to deploy, but always the latest build result.
Related
Git-flow explains the following process for release branches -
Release branch should be forked from develop branch
Release branch should merged back into master branch, and a tag created from master branch.
My question is why is why should release branches be forked from develop and not master? Is there any benefit from doing so?
I can instead
Merge my develop into master
Fork a release from master and then tag the master...
How will that affect the version management?
You almost answered your question in one of your comments:
the purpose of master is to be a replica of a production ready stable code
Let me elaborate on that:
(1) That statement is correct. master is production-ready. According to git-flow every commit (being a merge from a release or hotfix branch) leads to a new release.
(2) If you merge develop directly onto master you might end up with instabilities. That's what we create a release branch for. We use the latest version of develop but test them, make some bug fixes, adjust configurations etc.
Only when everything is fine we actually merge onto master and therefore deploy to our users.
A final - but very important - note here:
git-flow is just one of many ways to organise your code. It's not a this is the one and only solution for everyone and everything. It's just a suggestions, a framework. Adjust it to your needs or use a completely different framework / idea if it does not work for you. I rarely used git-flow in the past 15 years exactly the way it's documented. We always made some adjustments.
One of them btw being very closely related to your question: We would deploy from release and only if that deployment works and reached our clients (Apple's review process, I tell you!) we would merge to master and tag that release.
So, there is this cool package I've found but it leaves a lot to be desired. Since it made more sense to modify it, rather than build a new one myself, I changed the code in the corresponding source directory (C:\Users[my username].julia\v0.4[package name]\src). I made sure to modify not just the base.jl file, but also the [name of package].jl one so that there are no issues with dependencies or the new functions I added. I tried running the package several times to ensure that Julia doesn't spit out any errors or exceptions (the original package had some deprecated stuff, which I also remedied). Still, I fail to use the additional functionality of the package that I augmented. Any help would be greatly appreciated.
I'm using Julia ver 0.4.2, on a Windows 7 machine. As an IDE I use Notepad++. Thanks
I'm not exactly sure what you tried, but here's a guess as to what's going on: if you've already loaded the package in your julia session, edits to the source files won't take effect unless you explicitly reload the package. There are some good workflow tips here, and more explanation of the module system here.
However, for a newbie the easiest thing might be to quit julia and restart.
As far as making changes to a package, as Gnumic commented, your best approach is to make a branch and commit your changes there. Once you become convinced your changes represent an improvement, consider sharing your changes with the rest of the world.
My team are finally moving from SourceSafe to TFS 2010, and we are trying to work out our strategy.
We need to be able to put bug fixes into the next service release whilst still working on the current service release. Basically, at some point we will stop bug fixing going in the current release (except a few critical ones) and pilot that release for a week or two. During this time we still want to be fixing bugs so we put them into the next service release. This is separate from the development that will be going into the next major release.
We like the look of the mature branching strategy that involves having a service release branch off of main, a hot fix branch off of service release, and a release branch off of hot fix. What we would then do is have the release branch as the one that we are piloting and still be able to add bug fixes to the service release branch. Then when we finish with the pilot and have made the last critical changes we merge the release branch back into main, via the hot fix and service release branches, and then create a new hot fix and release branch from the service release branch, which will be our next service release.
The big problem I have with this is that I want anything that goes into main to be fully tested. The release branch will be but as we merge it back into main it will pick up any changes that we have checked into the hot fix and service release branches. These changes will not have been tested at this point.
To get around this we are planning on making the devs shelve their changes in the service release branch until after the release has been merged into main. This doesn't seem like the best idea to me, but I can't think of anything else to do to handle this.
Has anyone else had to do something similar and have a better way of handling this?
I love the maven-versions-plugin but sometimes I forget to run it for a while. Is there a way to make a maven build fail (and thus have a continuous build fail) when certain important dependencies are out of date?
I think you're approaching this incorrectly. Mail yourself the output of the maven-versions-plugin if you want, but don't fail the build due to changes outside of your control.
Even more, why would you want to needlessly update to the latest versions? I have seen many tricky problems appear due to upgrades which have brought slight changes to previous behaviour.
This, in general, is a bad practice - to update versions automatically. There is no practical reason of using the latest version of any package. If the library you're using satisfies your requirements you should stay with this version for security/stability reasons. And forever.
I think that maven-versions-plugin is an anti-pattern itself.
ps. When and if you want to do integration testing of modules developed by different teams/programmers, it is "integration testing". Even in this case I still think that on-fly version updating is the wrong approach. Root project should not do this integration testing, instead, every sub-module (or JAR, in your case), has to be responsible for integration testing of itself together with the rest of the system. When a sub-module increases its version it has to validate whether everything is still fine, and only then has to release a new version to the repository. And when the sub-module is doing the validation it has to be dependent on statically specified version numbers.
I mean, can I use the com.sun.org.apache (all subpackages) classes as I use they from org.apache (in any Apache lib)?
Will the OpenJDK maintain this package up to date with apache updates?
And the JDK7 will maintain this package?
Where can I find information about that?
It is a very bad idea to use it. Once upon a time, Sun took a copy of Xerces, chock full of bugs. They made some changes. Perhaps they subtracted some bugs. We know that there are many very serious bugs that they did not subtract.
And they renamed it to com.sun.... for one reason: to tell you not to use it. At any time, in any point release, in any patch, they can change those classes incompatibly or remove them.
Further, these classes may not be in IBM's copy of the JRE, or Apple's, or (haha) Microsoft's, or JRocket.
If you want Xerces, use Xerces. To find information about this, read the Xerces-j mailing list archive for many stern warnings from the Xerces developers about the version forked by Sun.
The fact that the classes are formally 'public' means nothing except that Sun needed to be able to new them from some other package.
Err I wouldn't, just based on the fact that they're internal classes and there is a risk of them changing over time. Use the org.apache classes instead.
No idea about the intentions with keeping them up to date, maybe try posting a message on the openjdk forum:
http://mail.openjdk.java.net/mailman/listinfo
My understanding is that this is a fork of the apache code. At one point they were the same, but no more. So you can't count on the same bug fixes being present in both versions.
If documentation for this package says that it is public, then it's OK to use.
Otherwise they can pool a floor underneath you when they decide not to support it in the future.
Usually, you should not rely on anything other than java and javax in JDK.