Would it be possible to pre-populate the GIT version with an increment of the last version on publish?
Not sure if that is possible or not. Basically the version simply adds a tag to the commit. The tag does not have to be numbers. Ultimately, I would like it to simply display the last version number so I can set the new version. Would save having to look up the previous version.
With everyone having their own system for versioning it may be hard for it to predict what the next version should be.
I voted for it.
The industry standard for versioning is semantic versioning. Wappler would need to scrape through your recent commits to determine if this is a Feature, Bug, Chore, etc., commit and then add the version number accordingly.
There are already completely free-to-use tools for that. This is usually done automatically when you push to master by a Pipeline at your git repo provider. At GitLab, it’s usually defined in the pipeline, and you can integrate it with GitHub actions at Github.
I’m using this for my versioning: https://github.com/semantic-release/semantic-release
So if I commit something with the commit message feat: create user roles, it automatically determines it as a feature, increments the version accordingly, and writes an automated changelog.
I don’t think Wappler should integrate automated versioning since it is already solved and would require a deeper git integration than what’s currently available inside Wappler. I don’t believe that the goal with Wapplers git UI is a full-blown git integration.
2 Likes
This is a good idea. Makes it easy for those of us who just use a simple numbering system but doesn’t add any complexity for those who want to use a different versioning system as they have to delete what’s there now already.
If things are going to be set automatically for us it should be based on good practices. Semantic versioning is considered good practice 
Do you think there is a downside for Wappler to simply put the last version number you used into this field as @brad suggested rather than the generic 1.0.0 that it does now?
I don’t need something as complex as what you’re using. I basically just increment myself based on the normal [major].[minor].[patch] standard and then write in the message what the changes were.
From what I can see, putting the last version used into that field would help myself and others who do their own versioning but wouldn’t negatively impact those who use something more complex?
@Heather_Mann A hint with the last pushed tag next to or above the input might be better. If Wappler adds the last tag to the input and someone who is new to git clicks on commit without changing the value then this will cause an error unless Wappler forces the commit which would overwrite the previous tagged version.
1 Like
I think it’s a great idea to just have it there as info, rather than prefilled. As it is now a user might do 1.0.0 if they don’t know how it works so probably better to have that field empty in the first place.
What do you think @George? Leave the version number input field for GIT blank but have the last version, maybe as a tooltip, that shows the last version committed?