ഓട്ടോപൈലറ്റിലെ പതിപ്പ് നമ്പറുകളും മാറ്റലോഗുകളും

ഒരു ചെറിയ ആചാരവുമായി ബന്ധപ്പെട്ടായിരുന്നു റിലീസ്. ആരെങ്കിലും തീരുമാനിക്കുന്നു, സമയമായി എന്ന്. അവസാന പതിപ്പിൽ നിന്നും അവർ കംമെറ്റ്സ് നോക്കുന്നു, എന്തൊക്കെ മാറ്റങ്ങൾ ഉണ്ടായി എന്ന് ഓർക്കാൻ ശ്രമിക്കുന്നു, അത് ഒരു ചെറിയ പതിപ്പാണോ അതോ പ്രധാന പതിപ്പാണോ എന്ന് ഊഹിക്കുന്നു, കൈകൊണ്ട് ഒരു മാറ്റങ്ങളുടെ രേഖ എഴുതുന്നു, അത് ടാഗുചെയ്യുന്നു, ഒന്നും മറന്നിട്ടില്ലെന്ന് പ്രതീക്ഷിക്കുന്നു.

ആ പ്രക്രിയ ഓട്ടോമേറ്റ് ചെയ്യുന്നത് സാധാരണയായി കൈകൊണ്ട് കൈകാര്യം ചെയ്യുന്നതിനേക്കാൾ മികച്ച ഫലങ്ങൾ നൽകുന്നു.

സെമാന്റിക് വേരിയൻസിംഗ്, ലളിതമായി

മിക്ക പദ്ധതികളും സെമാന്റിക് വേരിയൻറിംഗ് (സെംവെര്): MAJOR.MINOR.PATCH, പോലെ 2.4.1.

• പാച്ച് (2.4.1 → 2.4.2): ബഗ് പരിഹാരങ്ങള് , പുതിയതും തകര് ന്നതുമായ ഒന്നും ഇല്ല.
• ചെറിയ (2.4.1 → 2.5.0): പുതിയ സവിശേഷതകൾ, പിന്നോക്കം അനുയോജ്യം.
• മേജര് (2.4.1 → 3.0.0): മാറ്റങ്ങൾ ലംഘിക്കുക. ഉപയോക്താക്കൾക്ക് എന്തെങ്കിലും മാറ്റം വരുത്തേണ്ടിവരും.

പതിപ്പ് നമ്പര് നിങ്ങളുടെ ഉപയോക്താക്കള് ക്ക് ഒരു വാഗ്ദാനമാണ്. ചെറിയൊരു അപ്ഗ്രേഡ് സുരക്ഷിതമായിരിക്കണം. ഒരു പ്രധാന കാര്യം ശ്രദ്ധിക്കേണ്ടതാണ്.

സാധാരണ കരാറുകൾ

പതിപ്പുകൾ ഓട്ടോമേറ്റ് ചെയ്യുന്നതിനുള്ള തന്ത്രം കംമിറ്റ് മെസേജുകൾ യന്ത്രം വായിക്കാൻ കഴിയുന്നതാക്കുകയാണ്. സാധാരണ കരാറുകൾ ലളിതമായ ഒരു നിയമമാണ്:

feat: add Apple Pay to checkout
fix: handle empty cart in order summary
docs: explain retry configuration
chore: update dependencies
feat!: remove deprecated v1 payment API

• feat ഒരു പുതിയ സവിശേഷതയാണ്, അതിനാൽ ഒരു ചെറിയ ഒരു ബമ്പ്.
• fix ഒരു ബഗ് പരിഹാരം എന്നാണ് അർത്ഥം, അതിനാൽ ഒരു പച്ചില ഒരു ബമ്പ്.
• ! അല്ലെങ്കിൽ BREAKING CHANGE: അടിവശം എന്നതിനർത്ഥം പ്രധാനം ഒരു ബമ്പ്.
• മറ്റു തരത്തിലുള്ളവ (docs, chore, refactor, test, ci) സ്വയം ഒരു റിലീസ് സജീവമാക്കുന്നില്ല.

നിങ്ങള് ക്ക് ഒരു പരിധി കൂടി ചേര് ക്കാം: fix(api): ..., feat(ui): ....

എല്ലാവരും സ്ഥിരതയുള്ളവരായി തുടരാൻ, കൂട്ടിച്ചേർക്കുക കരാറിലേര് പ്പ് ഒരു ചെക്ക് ആയി ഉപയോഗിക്കുക, അല്ലെങ്കിൽ സ്ക്വാഷ് ലയനം ഉപയോഗിക്കുക, അവിടെ പിൻ അഭ്യർത്ഥനയുടെ ശീർഷകം കൺവെൻഷനെ പിന്തുടരുന്നു, ഇത് ടീമുകൾക്ക് പലപ്പോഴും എളുപ്പമാണ്.

നിങ്ങളുടെ കംമെറ്റ് ചരിത്രം ഒരു യന്ത്രത്തിന് മനസ്സിലാക്കാൻ പര്യാപ്തമാണെങ്കിൽ, നിങ്ങളുടെ ഭാവി സ്വഭാവത്തിനും അത് വ്യക്തമാണ്.

പ്രവർത്തനത്തിലെ റിലീസ്-പ്ലീസ്

ദയവായി വിടൂ.ഗൂഗിളിന്റെ, എന്റെ പ്രിയപ്പെട്ട ഉപകരണമാണ്. ഇത് നിങ്ങളുടെ പ്രധാന ശാഖയെ നിരീക്ഷിക്കുകയും ഒരു തുറന്ന "റിലീസ് പിൻ അഭ്യർത്ഥന" സൂക്ഷിക്കുകയും ചെയ്യുന്നു, അതിൽ അടങ്ങിയിരിക്കുന്നുഃ

• അടുത്ത പതിപ്പ് നമ്പർ, അവസാന പതിപ്പിൽ നിന്നും ചെയ്ത commits ൽ നിന്നും കണക്കാക്കിയത്.
• ഒരു അപ്ഡേറ്റ് CHANGELOG.md, സവിശേഷതകൾ, ബഗ് പരിഹാരങ്ങൾ, മാറ്റങ്ങൾ എന്നിവയിൽ ഗ്രൂപ്പുചെയ്തിരിക്കുന്നു.
• ഫയലുകളിലെ പതിപ്പ് ബംപ്സ് package.json, pyproject.toml അല്ലെങ്കിൽ ഒരു ഹെൽമും. Chart.yaml.

നിങ്ങള് റിലീസ് ചെയ്യാൻ തയ്യാറാകുമ്പോൾ, ആ പിൻ അഭ്യർത്ഥനയെ നിങ്ങള് സംയോജിപ്പിക്കും. release-please ഗിറ്റ് ടാഗും ഗിറ്റ്ഹബ് റിലീസും സൃഷ്ടിക്കുന്നു. നിങ്ങളുടെ സാധാരണ പൈപ്പ്ലൈനിന് ടാഗ് കാണും, അത് നിർമ്മിക്കുകയും പ്രസിദ്ധീകരിക്കുകയും ചെയ്യും.

name: release-please
on:
  push:
    branches: [main]

permissions:
  contents: write
  pull-requests: write

jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - uses: googleapis/release-please-action@<sha> # v4
        with:
          release-type: go

എനിക്കിഷ്ടം ഒരു മനുഷ്യന് ഇപ്പോഴും തീരുമാനമെടുക്കുന്നു എന്നതാണ്. എപ്പോഴാണ് പിആര് സംയോജിപ്പിച്ച് റിലീസ് ചെയ്യാന് . ഈ ഉപകരണം എല്ലാ അക്കൌണ്ടിംഗും ചെയ്യുന്നു.

സെമാന്റിക് റിലീസ് ഓരോ ലയനത്തിലും പൂർണ്ണമായും ഓട്ടോമാറ്റിക് ആയി റിലീസ് ചെയ്യുന്ന ഒരു ജനപ്രിയ ബദലാണ്. പതിവ് ചെറിയ റിലീസുകളുള്ള ലൈബ്രറികൾക്കുള്ളതാണ്, ചില ആപ്ലിക്കേഷനുകൾക്ക് അല്പം ഉത്സാഹമുള്ളവ.

മാറ്റങ്ങളുടെ രേഖകൾ ആളുകൾ വായിക്കുന്നുണ്ട്.

ജനറേറ്റുചെയ്ത ചാഞ്ചിംഗ് ലോഗ് നിങ്ങളുടെ കമ്മിറ്റ് സന്ദേശങ്ങൾ പോലെ നല്ലതാണ്. ചില നുറുങ്ങുകൾ:

• കംപൈറ്റ് (അല്ലെങ്കില് പിആർ) തലക്കെട്ടുകൾ എഴുതുക ഉപയോക്താക്കൾക്ക് വേണ്ടി, നിങ്ങൾക്കായി അല്ലഃ "പരിഹാരം: കുറഞ്ഞ വിലയുള്ള സാധനങ്ങളുടെ ശരിയായ വില കാണിക്കുക", "ബഗ് പരിഹരിക്കുക" അല്ല.
• മാറ്റങ്ങൾ വ്യക്തമായി അടയാളപ്പെടുത്തുകയും, കമ്മിറ്റ് ബോഡിയിലെ മൈഗ്രേഷൻ ഘട്ടങ്ങൾ വിശദീകരിക്കുകയും ചെയ്യുക.
• എന്തെങ്കിലും വിശദീകരണം വേണമെങ്കിൽ സംയോജിപ്പിക്കുന്നതിന് മുമ്പ് റിലീസ് PR യുടെ മാറ്റലോഗ് എഡിറ്റ് ചെയ്യുക. അത് ഒരു ഫയൽ മാത്രമാണ്.

ട്രങ്കിൽ അടിസ്ഥാനമാക്കിയതോ ഗിറ്റ്ഫ്ലോയിലോ?

ഓട്ടോമേറ്റഡ് വേരിയൻസിംഗ് ഏറ്റവും നന്നായി പ്രവർത്തിക്കുന്നത് തുമ്പിക്കൈ അടിസ്ഥാനമാക്കിയുള്ള വികസനം: ഹ്രസ്വകാല ശാഖകൾ, പലപ്പോഴും പ്രധാനമായി ലയിക്കുന്നു, പ്രധാന എപ്പോഴും റിലീസ് ചെയ്യാവുന്നതാണ്. റിലീസുകൾ പ്രധാന ഭാഗത്തെ ടാഗുകൾ മാത്രമാണ്.

ഗിറ്റ്ഫ്ലോ, ദീർഘകാലം വികസിപ്പിക്കുക, റിലീസ് ചെയ്യുക, ഹോട്ട്ഫിക്സ് ചെയ്യുക എന്നീ ശാഖകളുള്ള, അപൂർവ്വമായ, വലിയ റിലീസുകളുടെ ലോകത്തിനായി രൂപകൽപ്പന ചെയ്തിട്ടുള്ളതാണ്. ചില ഉത്പന്നങ്ങൾക്ക് (നിർദ്ദിഷ്ട പതിപ്പുകൾ ഇൻസ്റ്റാൾ ചെയ്യുന്ന ഉപഭോക്താക്കൾക്ക് വിതരണം ചെയ്യുന്ന സോഫ്റ്റ്വെയർ പോലുള്ളവ) ഇത് ഇപ്പോഴും അർത്ഥവത്താണ്, എന്നാൽ മിക്ക വെബ് സേവനങ്ങൾക്കും ഇത് വലിയ നേട്ടമില്ലാതെ സങ്കീർണ്ണത കൂട്ടിച്ചേർക്കുന്നു.

എവിടെ നിന്നാണ് ഞാൻ തുടങ്ങേണ്ടത്?

പിൻ അഭ്യർത്ഥനയുടെ ശീർഷകങ്ങൾക്കുള്ള സാധാരണ കമിറ്റുകളെ അംഗീകരിക്കുക, ലളിതമായ പരിശോധനയിലൂടെ അത് നടപ്പിലാക്കുക, ഒരു റിപ്പോസിറ്ററിയിലേക്ക് റിലീസ്-ദയവായി ചേർക്കുക. കുറച്ച് റിലീസുകൾക്ക് ശേഷം, കൈകൊണ്ട് മാറ്റലോഗ് എഴുതാൻ ആരും ആഗ്രഹിക്കില്ല.

എന്റെ അഭിപ്രായം: റോബോട്ടുകളെ എണ്ണാനും എഴുതാനും അനുവദിക്കുക. എപ്പോഴാണ് വിമാനം കയറേണ്ടതെന്ന് തീരുമാനിക്കാൻ മനുഷ്യരെക്കൂടി ഇവിടെ നിർത്തുക.

ഡെസ്ലി