Hi Lutz, I also need support for Release Management, so I need a way to track version numbers.
In the past I have initially written a major version number to a List object in the structure file, then incremented a minor version number every time I run Compile & Build, creating a file copy of the .4DB and .4DC file with the version number appended to the filename. Then I can deploy those structures to QA, UAT, Production environments and know positively what code is where. That allowed Method_History to track all edits by developer, version number and date time while it also created an archive of all versions of the structure. Does the VC software (Git, SVN, Mercurial) support that? I’ve just started to work with Mercurial and the terminology and process is a little overwhelming, so I can’t tell how much I will need to change my workflow to move to an external VC tool. Thanks, Tom > On Dec 10, 2018, at 01:26, Epperlein, Lutz (agendo) via 4D_Tech > <4d_tech@lists.4d.com> wrote: > >> Maybe we need to consider moving team development from the centralized 4D >> Team >> Developer model to a distributed model using individual copies of 4D. That >> would >> match the classic development model and practice which non-4D developers have >> enjoyed for decades.... Is anyone doing >> this yet? I would try it myself, but I’m not a Partner at this time. > > We have been doing something similar for some time with the VC_Framework > component. The original version of the component doesn't support the > re-import of code so we extended it with an import function for methods. The > procedure is a bit inconvenient, you have to do an additional step (the > import) manually after checking out the code from the versioning system > (Mercurial in our case) but it works flawlessly. We use this workflow and the > vc_framework component since 4d V13. Look here if you are interested: > https://github.com/elutz/vc-framework-v17 > > A remark: we don't use it for forms. An export of forms is possible using the > VC_framework. But we don’t re-import forms, since this is not possible > before 17R3. (And we don't do much GUI development in 4D, it is web > development mostly). It might be possible with 17R3 but we have to extend the > component again. If we start with 17R3 (or later V18) I think we will adapt > the component using the new features. > > Regarding this new features in 4D V17R3 I think they are based mainly on the > code of this component, the exported results look very similar. But a more in > depth test with the 17R3 we didn't do yet. > > Regards > Lutz > > > -- > Lutz Epperlein > ---------------------------------------------- > Agendo Gesellschaft für politische Planung mbH > Köpenicker Str. 9 > 10997 Berlin > http://www.agendo.de/ > ---------------------------------------------- > > > ********************************************************************** > 4D Internet Users Group (4D iNUG) > Archive: http://lists.4d.com/archives.html > Options: https://lists.4d.com/mailman/options/4d_tech > Unsub: mailto:4d_tech-unsubscr...@lists.4d.com > ********************************************************************** ********************************************************************** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **********************************************************************
