Docker-sync: Release 0.5.0

[EugenMayer]

I would really love to plan the 0.5.0 release.

Are there any concerns right now? I would create a beta build in push it - are any of you already using the latest master builds for their teams long term already?

Looking at the milestone https://github.com/EugenMayer/docker-sync/milestone/23 i probable would delay #355 and #39 for now (since they are also kind of related) - but i am not sure about #304 - you have put quiet some work into the tests already @michaelbaudino - do you wan to force #304 for 0.5.0 - do you think its the right point due to breaking changes?

I would really love to finish #465 since this could be a key part in letting people understand how docker-sync native_osx works, why it actually working and why its really native speed. Also it explains, when talking in the issues, which point you are talking of.

0.5.0 has no intended breaking changes or migration tasks, AFAICs, its more there have been some rewrites and refactoring, but also tests ( than you @michaelbaudino !)

There have been a lot of litte improvements to various areas over the last months and 0.4.6 has a really grown userbase now, we reached 20.000 downloads on https://rubygems.org/gems/docker-sync.

The feature i will miss most in 0.5.0 is actually #342 - this would have been huge but i just cannot make up enough free time to work on it and do not want to delay 0.5.0 for that time beeing.

----

---

Release notes:

Features/Improvements

• Integrations tests - huge credits to @michaelbaudino
• FreeBSD support
• print sync time so you can see potential stalls earlier #431
• be able to set max_attempt in global configuration #403
• added support for d4m edge #478
• added diagram to explain how native_osx works #465
• upgraded terminal-notifier to 2.0.0 #486
• upgraded docker-compose gem to 1.1 #486
• upgraded thor to 0.20 #486

Bugfixes:

• default ip detection fixed
• fix several typos and docs #432 #409 #404 #396
• fix exceptions thrown #406
• unison mount destination #433
• fix issues with spaces in folder / paths when using unison #426

Unison image

There also have been some improvements to the unison image

• https://github.com/EugenMayer/docker-image-unison/pull/3

- https://github.com/EugenMayer/docker-image-unison/pull/2

Special thanks to @michaelbaudino who has done a incredible job

----

---

@michaelbaudino we might need to add some integration tests to the uid / group id parameter. In general, uid is very important and most probably used every single time, group_id can become important if your image is inflexible.

[michaelbaudino]

This is an awesome plan @EugenMayer ✨

In my opinion, we could split the task in multiple milestones, for example:

• 0.5 (_a.k.a._ the stability release) with current bugfixes, tests (for all strategies and features) and developer-oriented doc (#465)
• 0.6 (_a.k.a._ the user-experience release) with user-oriented doc (#39, #355) and user-friendly features (#304, #342)
• 1.0 (_a.k.a._ the serious one 🍾) with the removal of unwanted / deprecated features (are multiple strategies really needed anymore?)

Would something like that make sense?

Regarding stability, I think we still have an issue (#410) but I'm not sure what we can do about it (and if it's worth the effort trying to fix/workaround it…).

[michaelbaudino]

Regarding writing test, I'll try to write more of them (for all strategies, at least), but I'm open to any help 😇
@ignatiusreza would you be willing to write some tests for Linux?

[michaelbaudino]

@EugenMayer I'm also working on a refactor of the configuration-related code to make it more re-usable and more testable… any chance it could be integrated into 0.5?

[EugenMayer]

@michaelbaudino i totally like the "stability, usability, legacy" kind of roadmap - lets stick to it!

To the "Configuration-related code refactoring" - do you have an issue for that, if yes, lets continue there. I would say, it depends on what you are doing.

Tests, i would not actually focus on adding more test for all strategies but first try to cover up the most used one, and that is native_osx - this way we know, that features like uid/guid are implemented and continue to work ( since breaking uid support means breaking the whole stack for nearly all people )

[michaelbaudino]

Gotcha, @EugenMayer 👍

Do you plan to keep supporting other strategies in the future? Or to deprecate them all in favour of native_osx?

Also, would you mind creating an issue with the list of features / configuration options you'd like covered for 0.5 ?

[ignatiusreza]

@michaelbaudino sure, I unfortunately can't allocate too much time into open source for now, but I'll try to help where I can.. :)

@EugenMayer regarding tests, for stability, I'm kinda on the same both with @michaelbaudino here.. even though we shouldn't need to write separate tests for every single strategies, I think it would be good if we can have 1 configurable integration test suite, where we can swap in different sync configuration, which would cover the big picture.. things like, adding, updating, deleting (and maybe excluding?) files/folders should work relatively similar in all strategy (with the exception that rspec doesn't support delete).. wdyt?

[EugenMayer]

@ignatiusreza nobody did argue about the value of covering all strategies, i was managing time, which i expect everybody of us has only limited amount of. So covering what most people use should be a prio, thats what i mean

[michaelbaudino]

Mid-term question here: wouldn't the docker-sync-stack wrapper be part of what we'd want to deprecate (and totally remove for 1.0) ? 🤔

[EugenMayer]

@michaelbaudino well its used very often and people starting docker-sync prefer it. I would rather think about removing the part the is based on the docker-compose gem and use the cli directly, so we can use all features docker-compose offers and also do not have any middle layer anymore.

What was your reason to think about removing it?

[michaelbaudino]

Ho right. I had no reason, really, I just saw it mentioned in another issue and was wondering if we wanted to keep it since docker-sync is now daemonized by default… I just forgot it was also starting docker-compose in the same command. Nevermind me, then 😅

[EugenMayer]

0.5.0-beta1 is out - please help testing!

[EugenMayer]

0.5.0-beta2 released gem install docker-sync --version 0.5.0-beta2

[EugenMayer]

I decided to upgrade the gems #486 and released 0.5.0-beta3

gem install docker-sync --version 0.5.0-beta3

[EugenMayer]

I had very little feedback to 0.5.0 right now - it works for me, but please do not get shocked if there will be bugs if nobody is opting in for a test before the release :)

[michaelbaudino]

I've actually been using beta2 for a few days now (since last Thursday,
iirc) without any issue 💪
Installing beta3 now 👍

On Mon, Nov 6, 2017 at 8:23 AM, Eugen Mayer [e-mail]
wrote:

I had very little feedback to 0.5.0 right now - it works for me, but
please do not get shocked if there will be bugs if nobody is opting in for
a test before the release :)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/EugenMayer/docker-sync/issues/467#issuecomment-342066171,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABYVmSDENWEZg_Jbc4398suGLPKL_3tCks5szrPtgaJpZM4PtK-k
.

--
Michael Baudino
Alpine Lab
@michaelbaudino

[michaelbaudino]

Oops, beta3 doesn't seem available yet, actually 😕

On Mon, Nov 6, 2017 at 10:10 AM, Michael Baudino <
[email protected]> wrote:

I've actually been using beta2 for a few days now (since last Thursday,
iirc) without any issue 💪
Installing beta3 now 👍

On Mon, Nov 6, 2017 at 8:23 AM, Eugen Mayer [e-mail]
wrote:

I had very little feedback to 0.5.0 right now - it works for me, but
please do not get shocked if there will be bugs if nobody is opting in for
a test before the release :)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/EugenMayer/docker-sync/issues/467#issuecomment-342066171,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABYVmSDENWEZg_Jbc4398suGLPKL_3tCks5szrPtgaJpZM4PtK-k
.

--
Michael Baudino
Alpine Lab
@michaelbaudino

--
Michael Baudino
Alpine Lab
@michaelbaudino

[tripox]

I've had no issues with Docker for Mac Edge, 17.10.0-ce-mac36 (19824) and 0.5.0-beta2 so far and I've used it daily since the release. :)

[EugenMayer]

sorry, released 0.5.0-beta3 - got an exception, did not see it

[EugenMayer]

@tripox @michaelbaudino great news. Since i upgraded docker-compose to the latest minor, as the notifier, we could have new glitches now. So keep your eyes open 0.5.0 is just the right time to do that, or we delay those upgrades for months, which could have quiet a effect with docker-compose

[EugenMayer]

0.5.0-rc1 releases - 0 changes to the beta, thats just a pro-forma release. If we do not have any issues as in beta2, we will release - only hotfixes allowed now, nothing of a bigger change.

Anybody who had beta2 does not need to upgrade, anybody else who waited for the rc, it would be the best time now :)

[tripox]

@EugenMayer, just installed 0.5.0-rc1 and is testing. :)

[barat]

I'm using 0.5.0-rc1 second day with High Sierra and 17.11.0-ce-rc3-mac38 - everything seems to work nice except that if i fire docker-sync start from child directory, docker-sync will "traverse up" to find docker-sync.yml and then contents of current dir (not place where docker-sync.yml is) will be synced into sync container host_sync dir. Not sure if this happens with 0.4.6.

[EugenMayer]

@barat could you please test that with 0.4.6 so we at least know if it as it has been or behaves differently and needs fixing?

Thanks for testing!

[barat]

@EugenMayer IMO no matter what it should be fixed because of inconsistency. Docker sync - if started deeper in the project - should respect docker-sync.yml location. I cannot test 0.4.6 since I'm on High Sierra, and I assume, that 0.4.6 is not working with newest system/docker edge.

[donnykurnia]

@barat in this case, you must use complete path for src. I use this approach in my project. I put docker-sync.yml above my working dir, but I run docker-sync start from inside my working dir. Because I use the absolute path, docker-sync working as expected.

. in docker-sync.yml file will be populated using the current directory where the command executed, not where the docker-sync.yml file located. This is the same way docker-compose works.

[ignatiusreza]

@barat can you try adding the following to your docker-sync.yml?

options:
  project_root: 'config_path'

[EugenMayer]

Please create a new issues to discuss that further, sorry I should have take action before, my bad

[EugenMayer]

anybody vetoing a release on the weekend? I think weekend time is best to not interrupt teams, letting early adopters already try and steer the team when the week starts.

I would release as is, so as -rc1 / beta3 have been, no additions. It worked well so far

[tripox]

@EugenMayer, I have also tested with Docker 17.11.0-ce-rc3-mac38 (the newest version of edge).
No problems so far. 👍

[EugenMayer]

Release is out, fresh and tasty.

Thank you to _all_ of you for helping with docker-sync and this release in particular. All the feedback, testing, adjusting and discussions - it would not have happened otherwise.

Beside all that, biggest shoutout to @michaelbaudino who basically is repsonsible for 70% of the work gone into that release - thank you for helping out!