버전 번호는 어떻게합니까?

버전 번호는 어떻게합니까?

---

우리 회사는 제품을 만들고 있습니다. SVN에서 버전을 지정할 예정입니다. 그것은 기본적으로 웹 응용 프로그램이므로 기본적으로 일부 기능이없는 버전이 없으므로 항상 베타로 레이블 될 수 있습니다. 그러나 그것이 기업 제품이 될 것이기 때문에 나는 "불안정한 감시"를 원하지 않습니다. 어떻게 버전 관리를 하시겠습니까? 1.0은 안정적입니까? 빌드 날짜가 버전 번호 여야합니까? 너희들이 어떻게 생각하는지 말해줘!

---

[ 메이저 ]. [ 마이너 ]. [ 릴리스 ]. [ 빌드 ]

전공 : 정말 마케팅 결정. 버전 1.0을 호출 할 준비가 되셨습니까? 회사는 고객이 더 많은 비용을 지불해야하는 주요 버전으로 간주합니까, 아니면 무료 일 수있는 현재 주요 버전의 업데이트입니까? R & D 결정이 적고 제품 결정이 더 많습니다.

minor : 메이저 가 증가 할 때마다 0에서 시작합니다 . 공개되는 모든 버전에 +1

release : 개발 마일스톤을 달성하고 내부적으로 (예 : QA로) 제품을 릴리스 할 때마다이를 늘리십시오. 이는 조직의 팀 간 커뮤니케이션에 특히 중요합니다. 말할 필요도없이, 동일한 '릴리스'를 두 번 (내부에서도) 해제하지 마십시오. minor ++ 또는 major ++에서는 0으로 재설정하십시오.

빌드 : SVN 개정이 될 수 있습니다.

---

xyzg

g 단위의 증분이 불안정합니다. z의 (또는 RC) 증분은 안정적이며 버그 수정을 의미합니다.
y 단위의 증가는 안정적이며 새로운 기능을 의미합니다.
x 단위의 증가는 100 % 이전 버전과의 호환성없이 안정적이며 주요 릴리스입니다.

---

한 번은 대규모 프로젝트를위한 정교한 "버전 관리 스타일 가이드"를 작성했습니다. 프로젝트가 구체화되지 않았지만 스타일 가이드는 여전히 온라인에서 사용할 수 있습니다 . 그것은 내 개인적인 의견 일 것입니다. 아마도 그것은 당신에게 도움이되거나 영감을 줄 것입니다.

긴 텍스트이므로 구성 요소 버전 관리와 제품 버전 관리 및 그와 유사한 것들에주의하십시오. 또한 OSS 커뮤니티에서 인기있는 일부 버전 관리 체계에 대한 강력한 의견을 표명하지만이를 가지고 있습니다. ;-)

예를 들어 Subversion 개정 번호 사용에 동의하지 않습니다. TRUNK에서 개발을 계속하면서 릴리즈 된 버전을 유지하고 싶을 수 있으므로 유지 보수 브랜치를 설정하면 개정 번호 버전이 줄어 듭니다.

편집 : 요약하면 버전 관리 소스 파일, 구성 요소 및 전체 제품을 구분합니다. 구성 요소와 제품에 대해 별도의 xy versoning 시스템을 사용하며 둘 사이의 상호 의존성이 뛰어나 어떤 구성 요소 버전이 어떤 제품 버전에 속하는지 추적합니다. 또한 시스템을 중단하지 않고 알파 / 베타 / 릴리스 / 패치주기를 처리하는 방법에 대해서도 설명합니다. 실제로, 그것은 전체 개발주기에 대한 modus 피연산자이므로 체리 픽을 원할 수도 있습니다. ;-)

편집 2 : 충분한 사람들이 내 기사를 "좋은 답변"으로 만드는 데 도움이됨에 따라 기사를 다시 작성하기 시작했습니다. PDF 및 LaTeX 버전을 사용할 수 있으며, 더 나은 언어 및 설명 그래픽을 포함한 완전한 재 작성은 시간을 찾 자마자 따라 올 것입니다. 투표 해 주셔서 감사합니다!

---

Wikipedia에서 영감을 얻으십시오 : "소프트웨어 버전 관리"

또 다른 "신규"및 "상대적으로 인기있는"옵션은 시맨틱 버전 관리입니다.

요약:

버전 번호 MAJOR.MINOR.PATCH가 주어지면 다음을 증가 시키십시오.

1. 호환되지 않는 API 변경을 할 때 주요 버전,
2. 이전 버전과 호환되는 방식으로 기능을 추가 할 때 마이너 버전
3. 이전 버전과 호환되는 버그 수정을 할 때 PATCH 버전.

시험판 및 빌드 메타 데이터에 대한 추가 레이블은 MAJOR.MINOR.PATCH 형식의 확장으로 제공됩니다.

---

abcd

단위 :
- D : 버그 수정
- C : 유지 보수, 예를 들어, 성능 향상
- B : 새로운 기능
- : 아키텍처 변화

예를 들어 새로운 기능과 버그가 수정 된 경우 b 를 늘려야 합니다.

---

복잡한 엔터프라이즈 플랫폼 수준 종속성 관리 및 릴리스 버전 관리에 대한 경험을 바탕으로 Semi-Semantic Versioning 이라고하는 접근 방식을 추천했습니다 .

기본적으로 Semantic Versioning 2.0을 기반으로 하지만 엄격하지는 않습니다.

반 의미 버전 세그먼트 :

<primary.release.segment>[-<pre.release.segment>][+<post.release.segment>]

기본 릴리스 세그먼트 형식 :

마케팅, 메이저, 마이너 패치

각 세그먼트는 영숫자를 허용해야하지만 논리적 증분 변경에는 순수한 숫자가 권장됩니다.

SemVer와 마찬가지로 역 호환성 계층을 나타 내기 위해 Major, Minor 및 Patch 구성 요소 를 권장하지만 Marketing 구성 요소 앞에 추가하는 것이 좋습니다 . 이를 통해 제품 소유자, 기능 epics / 그룹 및 비즈니스 문제가 기술 호환성 문제와 관계없이 기본 구성 요소에 영향을 줄 수 있습니다.

다른 답변과 달리 기본 세그먼트에 빌드 번호를 추가하지 않는 것이 좋습니다. 대신 '+'뒤에 출시 후 세그먼트를 추가하십시오 (예 : 1.1.0.0 + build.42). SemVer는이 빌드 메타 데이터를 호출하지만 Post-Release Segment가 더 명확하다고 생각합니다. 이 세그먼트는 기본 릴리스 세그먼트 의 호환성 정보와 관련이없는 것으로 접미사 데이터를 선언하는 데 유용합니다.. 그런 다음 지속적인 통합 빌드에 각 1 차 릴리스 후에 재설정되는 증분 빌드 번호가 추가 된 이전 릴리스 번호를 부여 할 수 있습니다 (예 : 1.1.0.0-> 1.1.0.0 + build.1-> 1.1.0.0 + build.2-> 1.1.0.1). 일부 사람들은 코드 저장소에 쉽게 연결할 수 있도록 svn 개정 번호를 여기에 넣거나 git commit sha를 선호합니다. 또 다른 옵션은 핫픽스 및 패치에 릴리스 후 세그먼트를 사용하는 것입니다. 새 릴리스 구성 요소를 추가하는 것이 좋습니다. 버전이 효과적으로 왼쪽 정렬 및 정렬되므로 패치 구성 요소가 증가 할 때 항상 제거 될 수 있습니다.

In addition to the release and post-release segments, people often want to use a Pre-Release Segment to indicate almost-stable pre-releases like alphas, betas and release candidates. The SemVer approach to this works well, but I recommend separating numerical components from alpha-numeric classifiers (ex: 1.2.0.0+alpha.2 or 1.2.0.0+RC.2). Normally you would bump the release segment at the same time as adding the post-release segment and then drop the pre-release segment when you next bump them primary release segment (ex: 1.0.1.2 -> 1.2.0.0-RC.1 -> 1.2.0.0). Pre-release segments get added to indicate that the release version is coming up, usually just a fixed set of features for more in-depth testing and sharing that doesn't change minute to minute based on more commits.

The beauty of having all of this semantically defined in a way that covers almost all use-cases is that you can parse, sort, compare and increment them in a standard way. This is especially important when using CI systems for complex applications with lots of small independently versioned components (like micro-services) each with their own managed dependencies.

If you're interested, I wrote a semi-semantic parser in ruby. I needed to not just use this pattern but be able to manage other apps that used it.

---

"Version numbers" are a matter for your internal version control system. Release numbers are a different matter (and should be KEPT different).

Stick to a simple MAJOR.MINOR release system (like v1.27), where MAJOR is the compatibility level (version 2.x is incompatible with or at least majorly different from version 1.x) and MINOR is your bugfix releases or minor enhancements. As long as you follow the X.Y format, you can also use other systems like YEAR.MONTH (2009.12) or YEAR.RELEASE (2009.3). But really you're probably best sticking to MAJOR.MINOR unless you have a good reason not to.

Definitely don't use anything that doesn't fit the X.Y format, as it'll make it tough for distros, announcement websites, etc. to work with you, and that alone could seriously affect your project's popularity.

Use branches and tags in your (preferably distributed) version control system to mark specific internal version numbers as relating to MAJORS and MINORS respectively.

And yes, 1.0 should be stable. All releases should be stable, unless they're marked alpha, beta, or RC. Use Alphas for known-broken-and-incomplete. Betas for known-broken. RCs for "try it; you'll probably spot things we missed". Anything without one of these should (ideally, of course) be tested, known good, have an up to date manual, etc.

---

It's pretty popular these days to just use the Subversion revision number.

---

If it's in SVN then why not use the SVN revision number?

If you look at the bottom right of this web page you'll see the Stack Overflow version number which is the SVN revision number.

---

Versioning is up to you; I'd put 1.0 on the first version I was confident in. You may want to follow it up quickly with other versions, since some software vendors have given 1.0 a bad reputation.

You do want some way of tying the version number to the exact build used, but you probably want it to be nice and simple for your end users. Consider using standard version numbers, and tagging the SVN repository with the version number included.

---

While just going with the Subversion revision number is nice and simple, it does remove information from the version number. Users might consider this a bad thing.

I assume that your webapp will have some kind of deployment procedure, so that not each revision in Subversion is actually published. Since it is impossible from the "outside" (from the user's perspective) to determine when releases are being made, and how many revisions the code will undergo between them, it makes the numbers almost random. They will be increasing, and I guess it's possible to surmise some kind of distance from comparing two revisions, but not much.

Classical version numbers tend to "dramatize" releases, so that users can build some kind of expectation. It is easier to think "I have version 1.0, now version 1.1 is out adding this and that, that sounds interesting" than to think "yesterday we ran SO revision 2587, today it's 3233, it must be lots better!".

Of course, this dramatization can be inflated too, with companies picking version numbers that are meant to sound more interesting than is motivated by the actual differences in the product, I guess going with the revision number counters this a bit.

---

Version scheme: [major].[minor].[devrel][mark]
[major]: increment if you have a drastic change in development.
[minor]: increment if you have a minor change in development.
[devrel]: increment if you have a bug fix. Reset to zero if major++ or minor++.
[mark]: a, b or rc: a is an alpha release, b is beta release, and rc is a release candidate. Note that versions like 1.3.57a or 1.3.57b or 1.3.57rc is before the version 1.3.57. Start at 0.0.0.

---

We've spent way too much time deciding when to increment the major version. Some shops would rarely do it so you would have releases like 1.25.3 and others would do it for ever release giving you 15.0

I got fed up with that and convinced everyone the major release number is just the year and the minor is just a sequential release within the year. The users seemed to like it and it's a no-brainer to come-up with the next version number.

Year.Release.build

• year = current year
• release = sequence # of public releases with new functionality - reset to 1 every year
• build = incremented for bug fixes and internal releases

EDIT

** Now this was for an internal app that was continually enhanced **

This would probably not work for commercial apps where it's important to have major releases at different times of the year for marketing and financial purposes.

---

I have very little experience in the area. However, here's what I'd do:

1. Choose a scheme for numbering revisions and stick to it. Be consistent.
2. Each version change should represent a significant change. How small a change is significant and the levels of change that are reflected in the version number are up to you.

Of course, you can just use the svn revision number --- like many others have suggested!!!

I hope this helps.

---

The reason why this question exists is because we don't have a single agreed upon way to do configuration management.

The way I like to do version number is just increment integer from 1. I don't want a multi part version number that I will have to explain or document. And I don't want to use SVN rev number as that will require some explaining as well.

You would need some release scripts on top of SVN to make this happen

---

We use a simple major.minor.julian_date syntax.

Where;

• major - First release is 1 and then when we introduce major new features or changes so significant they are not backwards compatible increase this number.
• minor - The major milestone releases. For each build pushed by production this number increases.
• julian_date - The Julian Day the build was pushed to QA.

Example of the first release pushed to QA on 1/15 is -> 1.0.015
Example of the first release pushed to Production on 3/4 is -> 1.1.063

It's not perfect, but handy as we push builds to QA near daily.

---

Some good info here:

When to Change File/Assembly Versions

First of all, file versions and assembly versions need not coincide with each other. I recommend that file versions change with each build. But, don’t change assembly versions with each build just so that you can tell the difference between two versions of the same file; use the file version for that. Deciding when to change assembly versions takes some discussion of the types of builds to consider: shipping and non-shipping.

Non-Shipping Builds In general, I recommend keeping non-shipping assembly versions the same between shipping builds. This avoids strongly-named assembly loading problems due to version mismatches. Some people prefer using publisher policy to redirect new assembly versions for each build. I recommend against that for non-shipping builds, however: it doesn’t avoid all of the loading problems. For example, if a partner x-copies your app, they may not know to install publisher policy. Then, your app will be broken for them, even though it works just fine on your machine.

But, if there are cases where different applications on the same machine need to bind to different versions of your assembly, I recommend giving those builds different assembly versions so that the correct one for each app can be used without having to use LoadFrom/etc.

Shipping Builds As for whether it’s a good idea to change that version for shipping builds, it depends on how you want the binding to work for end-users. Do you want these builds to be side-by-side or in-place? Are there many changes between the two builds? Are they going to break some customers? Do you care that it breaks them (or do you want to force users to use your important updates)? If yes, you should consider incrementing the assembly version. But, then again, consider that doing that too many times can litter the user’s disk with outdated assemblies.

When You Change Your Assembly Versions To change hardcoded versions to the new one, I recommend setting a variable to the version in a header file and replacing the hardcoding in sources with the variable. Then, run a pre-processor during the build to put in the correct version. I recommend changing versions right after shipping, not right before, so that there's more time to catch bugs due to the change.

---

Or to use your 'thought' version number comma subversion number.. z.B.:

1.0.101 // revision 101, release

or 1.0.101-090303 // with release date, i use this

참고URL : https://stackoverflow.com/questions/615227/how-to-do-version-numbers