While developing a component sometimes we push the changes to the scope (bit export) so we can import and test the changes on other projects, these versions are useless (e.g: 0.0.0-test.1), so we clean them up after finishing working with the component. We'd to have a way of cleaning those test versions using bit remove component_name --ver 1.1.0 -r
I don't fully understand what you're trying to do but I think it will be better if you snap changes instead of tagging a new version and maybe even use a lane. Give it a try and tell me how it works for you.
In Bit, you tag your new versions incrementally. That follows the Semver conventions.
No need to delete older versions; use the newer ones.
But if so you can deprecate it. Deprecating is a nondestructive way to flag an outdated version.
Now, that put aside, you can always open a new developing lane. A lane is like a git branch. It bifurcates from the original path and allows for diverging. Once you are satisfied with the diverge, you can merge it back:
bit lane merge new-feature
Conclusion: you shouldn't delete versions. Create newer ones or depreacate. If what you want is to diverge from the main developing line, use bit lane. You can always merge it back.
Related
I'm still getting the hang of VS Code.
I want to make a react app using 2 different GET API URL endpoints but the exact same UI. In essence, I want to change just the base URLs between the 2.
I've tried creating a new branch in VS code to make 2 separate files but once I make edits in the master branch, the changes reflect in the new branch also.
Is there a way of making a different stand-alone branch from the VS code?
I've searched through the forums to no precise avail and I'm not that good at git. Thanks.
It is likely that your changes are being shown when you switch branch because you haven't commited your changes to a branch before switching.
Let's say you are on the master branch and make some changes. You can create a new branch new-feature and change your current working branch to new-feature bringing your existing changes across. This is useful because sometimes you will start to carry out some work before realising the scope is a bit too big and should be it's own branch.
If you want to keep the changes you have made on your current branch, you need to "stage" your changes with git add your_filename.here (or git remove). Once you have added and removed all changed files you want to keep on that branch, you need to git commit them. This is the step that finally adds the changes to the version history.
Now when you change to new-feature branch, your changes on master will not be there.
There are a number of GUI applications that make the git model more intuitive such as SourceTree, Github Desktop, and SmartGit
We have constant problem with project XML file (*.sqlproj). If the files are added/renoved/changed location then it automatically adds/removes records in some unexpected places. After that we have big troubles by merging it when somebody changes that file also.
We came to conclusion that we might sort it before checkin. We would alphabetically sort it and in that case merge tool will understand it much better.
So, my questions would be:
Is it possible to re-arrange sqlproj file somehow before EVERY check-in? Maybe there are somekind of options/tools that doing that already?
Are there any other ways to make developers life easier?
UPDATE:
Once again I got the same problem. sqlproj file was modified 3 times and I want to merge to production only the last change, other 2 are not tested yet. in the merge tool I have the option to add all these 3 new objects or leave it without changes. I am not able to select only the last change ...
EXAMPLE:
developerA created tableA and checked in;
developerB got the latest version of dev branch, created tableB and checked in;
developerC got the latest version of dev branch, created tableC and checked in. DeveloperC tested the code and ready to go to production. He tries to merge his code to QA and get's the conflict where he has an option only to go with ALL changes.
I understand the scenario you are running into very well. This typically happens when you have multiple work streams happening in the context of a single repository and you don't have a common promotion schedule (as in all work will go to QA at the same time and PROD at the same time).
There's a few ways I can think to get around this problem and there are pros and cons to each option.
Lock each environment until everything can promote together. Not realistic in most cases.
When you are ready to promote, create a promotion branch from source environment and take things out of the promotion branch that aren't ready to promote to destination environment. This allows devs to keep working and be able to promote without freezing.
Hybrid approach... Don't source control anything in Dev until it's ready to promote to test. Then either do option #1 or 2 from there onward.
Create a more flexible ecosystem that can spin up an environment for each Feature branch in order to demo/test with others(or at least allocate/rotate enough between the developers to accomplish the same objective). Once it's accepted promote. This is what we are working towards currently but building out the infrastructure and process when you have a ton of interconnected databases and apps that share them is a bit challenging to say the least (especially in the Microsoft world).
Anyways hopes this helps...
1 - what source control are you using? No source control that I am aware of understands the context of sqlproj files but this isn't normally a problem.
2.a - This shouldn't be a problem you get constantly, are you checking in/out regularly? I would only expect to see issues if different developers are making large scale changes to the projects and not checking out / checking in before and after.
2.b - It is also possible you are not merging correctly, if you take both both sets of changes then it is normally fine.
ed
My company is developing a system for 10 years. This system has 15 subsystems that are almost independent (they may use same libraries or packages or DBs), and these subsystems are building locally in separate teams, also a main simple system is developed to read subsystem configs and build a page with menu and submenu from configs(with shortcuts). Our company's product is the exe of this main system.
Unfortunately, we do not use a standard version numbers in our company. Now, we decided to force a standard in company, and I found Semantic Versioning a satisfactory standard, but I have some questions in our case:
How would the changes on subsystem version increase the main system version? Often, after even Major changes in a subsystem, the code of main system remains unaffected. I think changes in the main system should shape the version number of that system, but in this case it does not make sense. Is there any solution for versioning of large applications that consist of multiple subsystems?
You gave a link to MAJOR.MINOR.PATCH, and increment the
MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner,
PATCH version when you make backwards-compatible bug fixes
Any change in a subsystem might make the main system incompatable: Too much to keep track of.
Each subsystem should use their own version. In the main system you should have an overview of the dependencies and the own versioning.
You can manage this in different ways. One way would be using Maven and pom.xml files. Another way would be using a config file with the different versions.
Each team can develop their own code independent and assign Semantic versions.
Maybe some day you will put the shared libraries, packages and DBs in a repository and all teams can refer to them with their own pom.xml.
You are flexible this way. You might even want to make a second main system (for top clients or for free accounts?) and can change the pom.xml including/excluding subsystems. The second main system will have its own versioning.
From the SemVer FAQ:
What should I do if I update my own dependencies without changing the public API?
That would be considered compatible since it does not affect the public API. Software that explicitly depends on the same dependencies as your package should have their own dependency specifications and the author will notice any conflicts. Determining whether the change is a patch level or minor level modification depends on whether you updated your dependencies in order to fix a bug or introduce new functionality. I would usually expect additional code for the latter instance, in which case it's obviously a minor level increment.
I would apply this to your scenario as follows: If your main application takes upgrades of its dependent subsystems without having to make major changes in itself, it should increase either the minor or the patch version. You shouldn't need to increment the major version, as its own public API is still considered compatible.
If the main application makes use of new features added to the subsystems, it should be a minor version increase.
Otherwise, it should be a patch version increase.
I think you're on the right track for this - literally treat everything with a SemVer version as it's own thing.
If you need to rebuild an updated linked dependency then at the least it'd be a patch version update - if they're simply soft links (ie, someone can update the subsystem without rebuilding or needing fixes) then it's purely a case of wanting a version number of when it was changed.
Keeping to the SemVer idea, if things cause incompatible changes then pulling the highest change out could make sense. Ie - updating 5 subsystems at the same time, 4 are patch updates, and one a minor - you'd update the minor version of the main system only (and put them all into that single change). Same with major changes etc.
The other similar idea is to drop the changes slightly if the main build is purely an interface on top - any minor or patch changes would only cause a minor on it, and any major subsystem changes would cause a minor - that way you can keep the major for breaking front end changes etc.
Something to bear in mind is that you don't have to follow SemVer perfectly - consistency is the key for something like this - so you could update the patch level for when subsystem changes are merged in, and never reset it, while updating the minor and major versions only for the main system. (There are a couple of open source projects that work this way, I just can't remember which ones off the top of my head).
Not sure if it's any use, but you could look at some of the nodejs packages around and how they update their versions with differing dependency versions - they all include a list of what they use in a package.json file with the version listed in a certain format (ie, exactly x.y.z or >x.y.z etc - https://docs.npmjs.com/files/package.json#dependencies)
When run Pkg.update(), all package will be updated if it is not pinned or dirty.
But it is possible to update a special package(such as FackCheck)?
I have taken a little look on the Julia source code, but haven't fond the direct solution.
I know I can pin all packages and when want to update someone, just unpin the package then run Pkg.update(), but I think it is not a good way.
You can also navigate to the package directory and type git checkout master && git pull. You can say Pkg.free("SomePackage") when you want to go back to having the package manager take charge of it.
If you know which package version you want to use you can do something along these lines.
Pkg.rm("FactCheck")
Pkg.add("FactCheck", v"0.1.1")
But that will also fix FactCheck at that version so a Pkg.update() will ignore it.
The slightly more crude and manual variant would be:
Goto https://github.com/JuliaLang/METADATA.jl/
Search the Pacakge you want and the latest version
In the case of Factcheck that would be https://github.com/JuliaLang/METADATA.jl/tree/metadata-v2/FactCheck/versions/0.1.2
Now copy the value in sha1 file
cd ~/.julia/v0.3/FactCheck
git checkout $sha1 .
But in this case you might be missing potential requirements.
So assuming that what you wan is not a specific version but the master branch for the bleeding edge version you can simply do.
Pkg.rm("FactCheck")
Pkg.clone("FactCheck")
But now you are working with a potential unstable version.
So in the end the question is what specific use case do you have that warrants only updating one package. If you only update one package that might cause dependency issues so updating all packages simultaneously is the better option.
Where can I find information on migrating our customized pages from our current install of Bugzilla to the latest, Bugzilla 3.6?
I'm trying to get up to speed on how all of of the pieces come together to make Bugzilla work. I have a working installation of 3.6 in a VHD (we are running on Windows). Next, I just need to figure out how to move our customizations forward.
Thanks!
There are several categories of stuff that you must consider how to move forward:
changes to scripts and modules
If you've been making changes to the code directly, it should be just a matter of merging 3.6 onto your source tree. This can create a number of conflicts, and it can be an exercise in code archaeology to figure out the resolution.
Use this as an opportunity to jump on the code hooks bandwagon so that you have minimal (hopefully no) changes to Mozilla's source, which will make future upgrades a lot easier.
changes to templates
If you've been changing templates in template/en/default, then that's pretty much the same as the case above - you need to merge in Mozilla's changes. If you've been putting customizations into template/en/custom, then you need to evaluate whether you need to make any changes based on corresponding changes to the defaults.
changes to extensions
3.6 introduces some new architecture in the extension system. You'll probably want to dig into this page as much as I have:
http://www.bugzilla.org/docs/3.6/en/html/api/Bugzilla/Extension.html
You'll probably also want to look at the upgrading notes for 3.6:
http://www.bugzilla.org/releases/3.6/release-notes.html#v36_upgrading
Finally, what I didn't notice until I had manually converted an extension, there's a script that will do it for you!
http://www.bugzilla.org/docs/3.6/en/html/api/contrib/extension-convert.html
You may find it helpful to visit #mozwebtools on irc.mozilla.org. That's where all the cool Bugzilla kids hang out! They're happy to chat up customizations to your heart's content.