Imagine you are preparing a release, and you also have to make a hotfix. The docs say, you should merge the hotfix branch to master and develop branches. But what about the release branch? I guess I should also merge it here, right? Or should I merge the hotfix just to release and then realease back to develop?
Issue is debated here : https://github.com/nvie/gitflow/issues/177 , conclusion is that hotfix could be merged to the latest release branch with a post-flow-hotfix-finish hook.
Related
is there a way to know when a version of Flyway is going to get deprecated?, actually we were using 6.0.7 the last year and then got deprecated like 6 months ago, now we are using 6.4.1 but I tried to find something on the blog and documentation but there's nothing about some news of when a version is going to be deprecated, only when we run our java spring boot project we know that a version is not usable. And we're aware of this because there's a lot of changes in version 7+ that doesn't work with our project (tested version 7.0.1 and the app crashed) and we need to estimate the cost of the changes.
Any help would be appreciate, thanks.
Flyway releases via Maven OSS. Old versions are kept indefinitely and are outside of Redgate's control. In theory, all older versions which are currently available on Maven will continue to be available for all time.
Newer versions may deprecate features over time, but older versions will always be available.
Using ASP.NET Core 1.0, is it best practice to check in the project.lock.json file into source control?
Short answer: No, project.lock.file should not be checked into source control - you should configure the version control system to ignore it (i.e. add it to .gitignore if you're using git).
Long answer: The project.lock.json contains a snapshot of project's whole dependency tree - not just packages listed in "dependencies" sections, but also all resolved dependencies of those dependencies, and so on. But it is not like ruby's Gemfile.lock. Unlike Gemfile.lock, project.lock.json doesn't tell dotnet restore which exact versions of packages should be restored - it simply gets overwritten. As such, it should be treated like a cache file and never be checked into source control.
If you check it into version control, then most probably on other machine:
dotnet will think that all packages are restored, but in fact some packages might be missing and the build will fail, without hinting the developer to run dotnet restore
project.lock.json will be overwritten during dotnet restore and in most cases will be different than the version stored in source control. So it will be modified in almost every commit
project.lock.json will cause conflicts during merge
Actually you do want to commit your project.lock.json in git sometimes.
Checking your project json
For the exact reasons that, it shows you the dependencies you have used. Say:
Me as a developer works on an application, i hate every time updating packages so i add a package dependency to nuget package X = 1.*
I restore package i get version 1.2.4
The package maker just made a very stupid mistake, he broke something while just trying to make a fix and release 1.2.5
Person 2 checks out (or even worse release build kicks in).
Person 2 restores and gets version 1.2.5
Person 2 runs your application and find the application is broken.
Person 2 starts debugging and thinks there must be a bug in the software.
At this step 7 Person 2 could have seen in git that his lock file was changed and a newer version of a library has been downloaded, Which has not been tested by any of the other developers!
Downsides
Downsides of checking in this file is you might get allot of merge conflicts on continues updates of packages.
Alternative solution
Use only hard version dependencies (this is quite hard though for nuget). And only manually update to newer version once in a while.
Downsides
This doesn't work if you build a library for other people to use, since you pin them to a certain version of your dependencies.
Dependencies of dependencies still get resolved automatically so if you don't specify them yourself you can't guarantee there version on dotnet restore
Conclusion
If you want to avoid 'Works on my machine' quotes and the hell of constantly manually updating to newer version: Checking the project.lock.json.
And also build a CI/Release build check to test if this file wasn't changed compared to git, before you release (If your software is very critical)!
If this is not a problem and also automatically updating (to a potentially broken package) is not a big problem, you might not want to commit your project.lock.json.
No, it is just a lock file, really you should never check it in when a lock file exists (except if the program who locked it wants to check it into source control, in that case, exclude your lock file!).
I've tried googling for this one but unfortunately got nothing: is there any changelog for the meteor releases? The History.md in github does not include the changes between the releases, say 1.3-rc.5 and 1.3-rc6.
Are there any means to determine the changes between the releases apart from reading the github commits?
http://pastebin.com/raw/SJT7BXwc
Are these the droids you are looking for?
**Updated
We have a web application and occasionally a bug will creep up that needs to be taken care of and fixed. We are using subversion as our code repository. What I am wrestling with is at what point do you create a new branch or tag. We were thinking that if the application needed to be rebuilt or the MSI needed to be rebuilt then we would create a branch. In the case of something simple like a typo, we would just distribute out the offending .aspx page.
What are some of your strategies for branching and building strategies?
Currently, ours looks like this. We have a class library, and Web application. We make our corrections, copy over the changed pages/DLLs to the MSI Creator (Advanced Installer) then rebuild our MSI. We are debating on whether or not to use a web deployment project/MSbuild or something similar. We need it to be reproducible, reliable and simple.
When you release your code, you would "tag" it. Let's say you tag it with "ReleaseVersion_1.2.3.4"
The "trunk" would be your main branch. And you continue to develop there.
If a bug comes along for a customer who has the released code, you would branch from the "tag" ( "ReleaseVersion_1.2.3.4" ), and would hotfix something there.
Then you would most likely merge code from this HotFix back to "trunk".
That's the simplest way.
There are many options for branch strategies.
But if your code hotfixes are occasional, this one will work.
I use the 2.0.x version in my project, but recently I've started to see more and more bundles that support only the master branch
Should I migrate to the master branch?
It's not stable and may contain unfinished code. Also, there are a lot of break changes that haven't been documented yet. If you're starting a new project, then go for master, if you have already written some code, I'd better wait for the next 2.1 release (all bundles should support it).
Most popular bundles work with 2.0 too, but you must often use the branch for your symfony version, not a bundle's master branch.