repo commit tagsr re, tracking new directory layout

[grantmacken]

With 4.6 onward we are seeing files and directories moving around.

https://github.com/eXist-db/exist/issues/2506

is copied to eXist-db\src\org\exist\util\mime-types.xml but should end in eXist-db\exist-core\src\main\resources (or we should git rid of the one in EXIST_HOME at all, of have it copied from the resources

Changes like this obviously effect, the way we build our docker image. e.g In the above mentioned mime-types.xml this is symlinked from home to a special docker specific config dir,

What I suggest we do is do a tagged commit for repo before 4.6 Then tag commit when ever we have to make changes to our Dockerfile

i.e.

• repo tagged v0.0.1 provides Dockerfile suitable for building prior 4.6
  • repo tagged v0.0.2 provides Dockerfile suitable for building after 4.6

[duncdrum]

Yes pushing tags has been on my todo list. Although I d suggest starting with 1.0.0 for everything up to exist 4.5.0. With 4.6.0 being the next major release.

Will happen soon, gotta fix master builds first though...

[grantmacken]

@duncdrum Just to clarify, I am not talking about tagging and pushing to docker-hub repos but, making a tagged commit to this repo.

git checkout [commit] or git revert to where the Dockerfile was building correctly before 4.6 then make a tagged commit

git tag -a v0.0.1  -m ' dockerfile for existdb version 4.5.1 and under'
git push origin  v0.0.1

If the Dockerfile was building correctly on or after 4.6 do another tagged commit.

git tag -a v0.0.2 -m 'dockerfile for 4.6 '
git push origin  v0.0.2

What we achieve by doing this ...

• If someone still wants to build a docker image from the Dockerfile for eXist version x ... they could checkout the tagged commit for that version
• tagged commits will be shown in github - releases and tags section

We should make tagged commits, ONLY if, the 'Dockerfile' changes and successfully building an eXist image

[duncdrum]

yes we re on the same page

[duncdrum]

tags are live