Open vkuznet opened 3 years ago
I am confused why you need to match between python and go?
because I use dbs unit tests against both servers. Otherwise I need to adjust GO code to use your tagging naming convention which I don't use.
We are in the middle of DBS py2 to py3. If it is not a big deal to adjust your version schema to be the same as DBS, please do so. We will keep all DBS code as it is for now unless there is a bug to prevent regular use.
@yuyiguo , it would be mistake for me to change convention of releases since it will break the history. The dbs2go used vXX.YY.ZZ schema for release, while DBS python codebase used X.Y.Z-
Valentin, DBS used different version schema before and you suggested us using x.y.z schema. We took your suggestion. Now you are doing something differently :-)
From: Valentin Kuznetsov @.> Reply-To: dmwm/DBS @.> Date: Thursday, May 6, 2021 at 7:00 PM To: dmwm/DBS @.> Cc: Yuyi Guo @.>, Mention @.***> Subject: Re: [dmwm/DBS] Add additional regexp for dbs2go version tag matching (vXX.YY.ZZ) (#652)
@yuyiguohttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_yuyiguo&d=DwMCaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=8bursUuc0V63OwREQMBG2Q&m=n5sxrmoejsUE0BMYKezF163S14wEIQOKjEPZGkswJxA&s=YrKXaclaPtPE6LxCivVcAIE5UiJDujD_1dLoR3Gbl-I&e= , it would be mistake for me to change convention of releases since it will break the history. The dbs2go used vXX.YY.ZZ schema for release, while DBS python codebase used X.Y.Z-. As such they should both follow the same path since it keeps history consistent. That is the reason I adjusted unit tests regexp pattern. Once again it is not a big thing but it is useful to make unit test pass, otherwise either code should adapt to another release tagging convention (which I don't think would be correct in either case).
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_dmwm_DBS_pull_652-23issuecomment-2D833956078&d=DwMCaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=8bursUuc0V63OwREQMBG2Q&m=n5sxrmoejsUE0BMYKezF163S14wEIQOKjEPZGkswJxA&s=3QY8KUdT_hSFWJsD9CElz_IY_WBqVLuSEL_rieC3Z4A&e=, or unsubscribehttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AANROTRP4E4MWBTINTO4GPTTMMUSJANCNFSM44HU3X5A&d=DwMCaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=8bursUuc0V63OwREQMBG2Q&m=n5sxrmoejsUE0BMYKezF163S14wEIQOKjEPZGkswJxA&s=pyAJRruk6XeQINVnnh92SFvYXBXwPM21Ehit5LqQgrQ&e=.
usage of X.Y.Z or XX.YY.ZZ is desired, but use-cases are different. The former is better suitable for codebase with not frequent release cycles, while latter is better for more frequent release cycles. From the start I knew I need more frequent release cycles, and turns out it is true, I already had 159 releases. Putting them into X.Y.Z will make sorting looks ugly. That's the reason I follow when choosing and using specific release schema.
@yuyiguo , in dbs2go I use different set of tagging conventions, like vXX.YY.ZZ. Therefore, to make unit tests match both dbs python tags and dbs2go ones I made this PR.