I am new to Laravel Framework and I wanted to know what is the difference between the Master and 5.0 (can be found at the documentation page).
Thank you.
The 5.0 branch is the current stable release all bugfixes and patches go to this branch and that's the one you should use. (it is also the one composer will use when you create a new project).
The master branch contains the upcoming release. In this case 5.1. However it could be unstable or suddenly break features because things will change in the new release.
Related
We were using Sonarqube Enterprise Edition and it’s version is 9.2 and we upgraded it to 9.3 yesterday. So we always use latest version for Enterprise Edition.
I think Sonarqube New Code definition is working wrong. I will try to tell you with our example.
You can see what our project’s New Code definition is.
I think Sonarqube should calculate difference code from the previous version. But it did not do that.
P.S. We scan our repository’s develop branch on Sonarqube every night as scheduled. So the previous version is yesterday’s scan.
We work with feature branches in our repository. Basically, we create new feature branch from develop, then we develop our features in the feature branch. Sometimes it takes one or more weeks. We did a lot of commits in this duration. After we finish developing, we merge the feature branch to develop. And that night, Sonarqube scan develop branch again. I think the merged feature branch’s codes is all new code. But Sonarqube only considers commits made that day(last day). Previous commits’ codes are not shown in New Code reports.
I hope I was able to explain my problem.
Update 1:
I tried to fix the Sonarqube Project’s version nubmer. After that, the New Code definition shows as “Started 5 days ago”. As you can see the below image. It means it takes 5 days period.
But I tried to tell before. I want to see all merged branches, commits to develop in new code report for every day. Is there any other suggestions?
Thanks.
I was wondering how to build a development version rather than the latest version using Sphinx Read the Docs theme. Is there any place I can put like "development" indicating that it is a development version?
Take a look at how we do this for Pyramid. Development is on the master branch, and released versions are on numbered branches, e.g., 1.10-branch.
You also need to configure RTD to support multiple versions of your docs. In Pyramid, we point latest at the latest released version, not the development or master branch.
I want to upgrade my application from 5.4 to 5.5, at first I was totaly fine with working 5.4 but now it seems like I can really make use of the new errors page. I've seen some other changes going on too and I wonder if I upgrade it from 5.4 to 5.5 and if something goes wrong, what options do I have. The project is saved in a private repository, I know I probably have a chance to go back to previous versions easly, but after doing development in 5.5, am I gonna be in a deadend for solutions?
I suppose you are using GIT for SVN. Then just create a separate branch from master and upgrade and test it for a few days and if everything works fine then pull on production. Also, maintain a 5.4 branch for few days if you want to revert back. But it's very rare you will face any problem on 5.5 if you migrate correctly with through testing.
I have a large project running on Laravel 4.2 and now I would like to upgrade it to the latest release (5.4)
On the upgrading guide I can see the steps to upgrade from each release to the next one, but the 4.2 to 5.0 requires a fresh install. Hence the question: should I install 5.4 (and fix problems) or 5.0 (running each upgrade)?
I'm possibily using any Laravel functionality, and have organized repositories for my own custom methods; I also need to maintain the database. I need to upgrade because I would like to use event bradcasting with Laravel Echo.
Thanks
To those looking for an answer: update directly to latest version, then fix changes along the way.
Explanation:
At first I tried to upgrade version by version; it was a pain. Every single vendor had different packages for each version and that caused issues even before correcting the code. I couldn't start fixing my code because the installation requirements of the vendors were failing at a certain point of the upgrade process.
Upgrading directly to latest version requires the correction of many things, but at least those are only related to your code. In my case I had to remove Sentry (authentication), Laravel OAuth, and some others I don't remember in favor of some native packages which I hope will be maintained properly. The upside of this approach is that once you have all the packages you need installed you can work directly on your code... which is what you have to do anyway.
We'd like to increment the minor version of our application each time we create a new branch for release. So if, for example, the current version is 4.17 the next branch we create would automatically increment the version number to 4.18.
Our scheme is that the code follows the following path:
Dev -> Test -> Staging
so that the testing happens on code we think has the functionality required and only that code that passes testing is available for release.
Then when the time comes for a new release we take a new branch of Staging, so we have the following structure:
Staging
|----> Release 4.1
|----> Release 4.2
...
|----> Release 4.17
There is no cross pollination between the release branches.
So what we need is something that will increment the minor version number when a new branch is taken. We can reset the version number of the application in Dev/Test/Staging to anything that needed for this to work.
Is this possible with TFS/VS 2013 out of the box?
That is a bad smell!
You have to do that on one branch, and no in all... And not change the assembly number in a manual way...
The TFS Versioning could help you to do this.
In the community build tools you will find an activity called TFS Version. This tool can, in its default configuration, strip the version number from the build name. If you name your build for the branch to be mybuild_7.8.0$(.r) the tool can be configured to pick up that version and store it in a variable. You can then use that variable to update the AsemblyInfo.* file versions.
This is the correct way to do what you are asking. Do not check the changes in, and indeed set the checked in numbers to be 0.0.0.0. This way you will be able to identify when a cheeky developer has done a local push and when it came from a build server 😃
https://tfsbuildextensions.codeplex.com/wikipage?title=How%20to%20integrate%20the%20TfsVersion%20build%20activity&referringTitle=Documentation