Module bundle version number(s)?

[pwFoo]

I write a module which is separated by module functionality into two modules. Both share code (abstract php class) to prevent duplicated code.

How should I set version number(s)? Own version for each file? But I need a "bundle version" (for example module version added to PW module repo)?

Should I use file and module versions? Or only a "bundle" version?

[kongondo]

I always use bundle version - I view the whole thing as one package and also don't want to confuse users...In my commit I enter notes to specify if a version bump 'was just to keep up with updated module xx'.

But am not saying this is the 'correct way'

[LostKobrakai]

The version for the modules directory – and therefore the relevant for showing updates in the admin backend – is the module, which corresponds to the classname one sets in the settings. For example my Inputfield Chosen Select does get the version number of InputfieldChosenSelect.module, while the version of InputfieldChosenSelectMultiple.module is irrelevant (not the best way, as I could certainly edit only the last one and nobody would notice). In a processwire installation this classname is also the name of the wrapping folder inside of /site/modules/.

While a base module for installing each parts and providing a "bundle" version number is certainly a good way to go I'd say you should at least use a dedicated version for each separate module. Even just to be in line with how processwire itself handles this. I've not seen version numbers in included php files that Ryan coded, which aren't modules on their own.

[pwFoo]

As example.

I write two modules FrontendUserLogin and FrontendUserRegister. Both modules share code by an abstract php class (form handling, style / script loading, ...). I bundled the login and register module with the abstract class to FrontendUser.

So I have two modules with module version. At the moment there is no bundle / repo version.

If I move the module info to the abstract class both modules will share one version...

If I separating the modules I have to duplicate the shared base source code.

Another way could be to bring both modules together.

[LostKobrakai]

You've essentially three options: 

1. Pack the abstract class together with both your modules. You can use the bundle module to install the two other or leave it to the user to install them independently. Looks like this as folderstructure: FrontendUser -> ( FrontendUser.module, FrontendAbstract.php, FrontendUserLogin.module, FrontendUserRegister.module)
   This way users can only upgrade the whole bundle via the admin interface, but I think that's not a problem here.
2. Distribute the modules independently (FrontendUser, FrontendUserLogin, FrontendUserRegister) and require the base module with the abstract class from the subordinate ones.
3. Duplicate the abstract class to each module. 

[pwFoo]

Thanks. I thinking about a merged module FrontendUser with login, logout and register functionality...

The main diff are the form fields (username, password vs. username, password + validation, email) / callback hooks (check form errors vs. already in use) and some lines of code. Each functionality could need only one custom method (login / auth user, logout user, save temp user). Shared code is form handling (minimal code because based on FormHelper module). So a merged module shouldn't have a relevant overhead.