search

wpsharks / phings

Just a few Phings we like to use :-)
GNU General Public License v3.0
1 stars 0 forks source link

Find a way to avoid unnecessarily including modified version numbers in commits #147

Open raamdev opened 7 years ago

raamdev commented 7 years ago

@raamdev writes...

@jaswsinc I noticed while reviewing your PRs that you seem to be unnecessarily committing lots of version number changes. Is there a reason for that? Those changes should only be committed when actually do a release. e.g., https://github.com/websharks/comet-cache-pro/pull/296/files#diff-9c67df51b0f1878fbf046f9c24645a45

@jaswsinc writes...

It's mostly from me being lazy and running phing full-build-all -D composer-lock-delete=true instead of just phing full-build or composer update. I tend to do that from time to time so I can make sure composer.lock is updated with the latest dependencies. I also do that to bump the version for testing the VS upgrades periodically; i.e., while I'm working on other things, just in case it helps me spot something in the upgrade handlers that is impacted by other changes.

So the short answer is that I'll try not to do this as much, but I'm not sure if that will be a good thing or a bad thing yet. Hmm, is it really a problem for the version numbers to get bumped in the dev branch as they are merged in? Aside from it making the diffs a little more difficult (just slightly), my feeling is that bumping those versions is something that helps me.

Keep in mind that I don't build distros, then test. That slows me down. I keep the active codebase in WordPress while I'm making changes; i.e., I don't install a ZIP file.

@raamdev writes...

My feeling is that any changed version number that gets committed adds to all sorts of confusion, not only when I'm reviewing the source code ("hey! what's this change here?! Oh... it's not really relevant to anything.... Oh! what's this? Oh, same thing, not relevant...") but also because in the future when going back and researching a bug or trying to figure out where things changed, it's confusing to see version numbers that never really existed (i.e., were never really released).

I can see the need to do whatever is necessary to help you with development, but then maybe those phing routines shouldn't change the version number, at least not without a flag (that I only run when doing a release, or that you use when testing a version upgrade and then intentionally don't commit).

The way I look at it: There's a right way to do things and a wrong way. Then there's a messy way. :-) We should always be striving to do things "the right way".

@jaswsinc writes...

I can agree with those thoughts also. I'll keep this mind when I'm working in Phing soon too. I have a few issues piling up over there and plans to dig that project back out again soon and see if I can knock out a few open issues. I like the version changing on my side, but I also agree that it makes the diffs messy and it's not really the proper way to do it.

jaswrks commented 7 years ago

Noting that this is already built-in via phing build-all or phing build instead of phing full-build-all or phing full-build. I just need to start using those instead. Bad habit.

jaswrks commented 7 years ago

Reopening this as I just discovered one of the reasons I was forced to do this in the past. Whenever I want to release a new bleeding edge, the build routines need to run (in full) to update the software and prepare it for a new bleeding edge.

So the ability to do a full build, update versions, etc... prior to actually doing a release, is still desirable. However, in the future it would be nice to make this possible without needing to commit those version changes.