Update versioning to use %year%.%month%.%day% (eg, "17.01.12")

[quinthar]

Let's aim to do a monthly release, with "dot releases" if there are just small bugfixes and cleanup, and "full releases" if there are meaningful functional changes. In this case it looks like there are no externally-visible (eg, interface-changing) functional changes, so we'd just do a dot release. Thoughts?

Also, any thoughts on how to put plugins into a dynamically-loading library such that we can use the public repo for our actual servers, and just separately version/release our internal Expensify plugin? This'll help ensure the public repo stays up to date, rather than us continuously struggling to remember to package and release the latest changes.

Cc: @tylerkaraszewski @righdforsa @cead22

[quinthar]

For now, let's just release HEAD as v1.2 and we can worry about a more deliberate approach later.

[quinthar]

@righdforsa @tylerkaraszewski - Now that we've moved all of auth into its own .so, can we start formally versioning each new Bedrock release? Also, I'm wondering if calling it 1.0 is misleading, given that we've been using this in production at scale for many years. I vote we use an Ubuntu-like numbering scheme, which just represents the year and month. So, the next release would be Bedrock 17.1.

[righdforsa]

No objection with the numbering scheme. I think just releasing HEAD each time we do a deploy is a pretty good process. One thing that will help a lot is moving to using open-source bedrock, which is possible now that auth is in a separate .so file.

…

On 26 December 2016 at 14:33, David Barrett ***@***.***> wrote: @righdforsa <https://github.com/righdforsa> @tylerkaraszewski <https://github.com/tylerkaraszewski> - Now that we've moved all of auth into its own .so, can we start formally versioning each new Bedrock release? Also, I'm wondering if calling it 1.0 is misleading, given that we've been using this in production at scale for many years. I vote we use an Ubuntu-like numbering scheme, which just represents the year and month. So, the next release would be Bedrock 17.1. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#57 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABlFPzGjmE6ymberMAesnZm3dl749wZRks5rL9AygaJpZM4K2hei> .

[quinthar]

Yep, I'd love to do this, and then re-announce to the list. On Mon, Dec 26, 2016 at 8:57 PM, Christopher Peters < notifications@github.com> wrote:

…

No objection with the numbering scheme. I think just releasing HEAD each time we do a deploy is a pretty good process. One thing that will help a lot is moving to using open-source bedrock, which is possible now that auth is in a separate .so file. On 26 December 2016 at 14:33, David Barrett ***@***.***> wrote: > @righdforsa <https://github.com/righdforsa> @tylerkaraszewski > <https://github.com/tylerkaraszewski> - Now that we've moved all of auth > into its own .so, can we start formally versioning each new Bedrock > release? Also, I'm wondering if calling it 1.0 is misleading, given that > we've been using this in production at scale for many years. I vote we use > an Ubuntu-like numbering scheme, which just represents the year and month. > So, the next release would be Bedrock 17.1. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#57 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/ ABlFPzGjmE6ymberMAesnZm3dl749wZRks5rL9AygaJpZM4K2hei> > . > — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#57 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAjG0n7Hlp_PRJtzbu0Wr1JOM_Clu7Krks5rMCpDgaJpZM4K2hei> .

[quinthar]

Bump. @righdforsa - Any eta on us using the public apt-get repo, and updating it regularly?