I was wondering whether is it possible to have automatic versioning (following the SemVer convention) in Flutter, set in a GitLab/GitHub/BitBucket pipeline.
Obviously, all git commits will follow the Conventional Commits structure.
I searched a lot but could not find anything helpful. All I could find was a way to create automatic changelog based on the commits (but that is not my situation here).
Has anyone encountered the same problem and found a solution?
Related
This might be a basic github question, but I'm having trouble finding the right keywords to google because I don't know the terminology. Apologies and thanks in advance.
I've noticed with library dependencies in library.json, under "dependencies", there is often a github remote repo link with a version number after the #
For example
https://github.com/codewitch-honey-crisis/htcw_ili9341.git#1.0.0"
What is that exactly after the #? A branch? A release?
More importantly, how do I make my github repo expose these. Like, I want to make a 1.0.0 one now for htcw_ili9341.git but later I may want to make 1.0.1
Using the github website, and/or the command line, how do I go about this?
It would be really helpful if you explained as you went as well.
So you know where I'm coming from with this, I've been using github for awhile but only for the most basic things, and driving it all through VS Code for the most part, sometimes resorting to the web interface and only occasionally dropping to the command line, which I've done a handful of times to resolve merge conflicts. I'm not an expert, but not completely new to it either.
anything after # is never posted to the server. It's basically a comment in this specific instance.
Having used various version control systems in the past including TFS, the whole concept of file revisions was always easy to interpret and grasp. If I ever wanted to reference the latest version of files for instance, I only needed to identify what was listed as the latest changeset (or whatever terminology was used by that particular vcs) and that was pretty much it. Very easy.
I am a relative newbie to Git and so with the transition of TFS to Azure DevOps, I really find it confusing trying to get a handle on the concept of file versioning in Git. I have a couple of questions which are perhaps best depicted by the below screenshot.
For example,
What is HEAD and what is the distinction between it and the latest commit?
Why is a HEAD id different from the last commit id, when a file comparison run against the two ids indicates they are identical? In my case anda from the image below, this would be 43593c12 and f493628c respectively?
.
HEAD in Git is essentially a commit pointer of your local repository.
The most important thing to note here is that HEAD is subjective (locally scoped) and would normally differ for every clone of repository.
The concept of latest commit in Git is ambiguous, since Git is a distributed system - hence "latest" is not clearly defined.
Generally, if you're new to Git, I recommend spending 1-2 weeks of time and reading Git Book thoroughly - https://git-scm.com/book/en/v2
Specifically for your current question take a look at The Three States and Branching basics.
I want to open the issues tab when I open repository because I made a repository just for collecting the tasks for all my project , How can we do that ?
As #VonC has said, this is NOT configurable. It seems that what you require is an issue tracker and not specifically a repository. This articles may help you find an issue tracker that fits your purpose:
http://mashable.com/2014/02/16/bug-tracking-apps/
http://www.thegeekstuff.com/2010/08/bug-tracking-system/
Github's feature for referencing issues in commits automatically just by using the # and referencing commits in issues using the commit hash id is powerful. But is it a maintainable or scalable approach to handle issues from different repositories in one central repository? I do not think so. Issues are important in project development and should be kept organised the same way we keep code clean and organised.
However, this does not mean that it is not possible to maintain your issues in a single github repository. Instead of trying to have the issues tab open automatically, you may create a manual, as a README, for instructions on utilizing the reported issues. This manual will be shown to users visiting the repo. See https://github.com/keybase/keybase-issues as an example. You may find this github article useful in referencing issues.
This doesn't seem to be configurable.
That means you need to open your repo directly at the "Issues" page:
https://github.com/<username>/<reponame>/issues
I just found the Mottie/tablesorter repository after implementing the –what I thought to be– original repository from Chrisitian Back.
The description of Mottie's repo says:
Github fork of Christian Bach's tablesorter plugin + awesomeness
Now when reading this, three questions come up:
Why is this one not marked as fork on github (usually if this is a little hint below the repository name if it's a fork - that's missing on this repo)
Is "+ awesomeness" in the repository description something specific (e.g. a JS lib) or is this just some kind of "marketing term" for this repo?
What are the major differences between this repository and the original one from Christian Bach?
Can I easily migrate to Mottie's repo (as it is much more vivid according to its Pulse)? What do I have to watch at when doing so?
As I mentioned in the issue that was opened:
Christian Bach added his GitHub repository on May 20, 2014, whereas my fork was created somewhere around June 2011. So there really isn't a way for me to fork from his repo now. Nothing is missing, except for a few documented changes to the options; but a lot has been added.
"+ awesomeness" was just added to distinguish this fork from the original; especially because most of the widgets available for this fork will not work with the original. I have tried different methods to help distinguish this difference... "+ awesomeness" is just one way. Now the main document page has "unoffical fork" at the top to try to make it more obvious. Eventually, I plan to rename this fork to Abelt (which has lots of breaking changes) to avoid further confusion.
I have some documented differences on the summary wiki page. Sadly, I haven't had the time nor the inclination to update it since version 2.7 (currently we're on v2.18.3). That should at least get you started. Other than that, I feel like the documentation is pretty extensive, so you can always fall back on it if you have questions.
If you have a basic set up working with the original tablesorter, then there is shouldn't be any major changes needed to just swap out the original with the forked version. With a more complex set up, you might have to tweak a few things. Post some code, I'll try to help. It won't be as bad as you think.
If I have to change the source code of an app(Email, Browser, etc) for some custom requirement, I wonder how I should maintain the changes so that I can upgrade to the newer version of the app later when it's available.
I can thinking of maintaining the diff patch and applying to the newer version later but I am wondering if there are any best practices. Is it good to just fork off a branch and keep merging the newer changes into it?
Thanks.
Sony several times described their process. Here is the links:
http://developer.sonymobile.com/2013/07/25/explaining-the-software-upgrade-process-and-its-improvements-for-android-4-3/
http://developer.sonymobile.com/2011/12/07/ice-cream-sandwich-from-source-code-release-to-software-upgrade/
You should follow the disciplines that:
Keep your modifications aside from the original code as much as possible - this will save your effort if you have to do merge code later
Record your modification work in an appropriate way, you need to know why you made these changes and how you did it.
Don't expert to do a simple merge since the changes might not be fast-forward. Rebase your repository first and pick your changes and apply carefully.