Update RELEASE - Revision history

Paul Blankenbaker at 13:30, 13 April 2013

2013-04-13T13:30:05Z

← Older revision		Revision as of 09:30, 13 April 2013
Line 1:		Line 1:
	This step is not typically required when you plan on continuing work in the same major release area. For example, if you just produced a ''~~2.13.0~~'' release and expect to continue supporting it and possibly having more ''~~2.13.0~~'' maintenance releases, you will likely ''not need'' to update the variables mentioned below.		This step is not typically required when you plan on continuing work in the same major release area. For example, if you just produced a ''18'' release and expect to continue supporting it and possibly having more ''18'' maintenance releases, you will likely ''not need'' to update the variables mentioned below.

	If necessary, you should change the value of the RELEASE and/or RELEASE_LAST variables at the top of the include/data/configure.in script to their logical values.		If necessary, you should change the value of the RELEASE and/or RELEASE_LAST variables at the top of the include/data/configure.in script to their logical values.

	The following assumes that you just published a ''~~2.13.0~~'' release and are now planning on moving to a Fedora 15 base.		The following assumes that you just published a ''18'' release and are now planning on moving to a Fedora 20 base.

	; RELEASE_LAST		; RELEASE_LAST
	: This should be set to the version just released (''~~2.13.0~~'' in this example).		: This should be set to the version just released (''18'' in this example).

	; RELEASE		; RELEASE
	: This should also be set to the version you will now be working on. Since, in this example, we are moving to a Fedora 15 base, it should be set to ''~~2.15.0~~''. Had we decided to continue using Fedora 13 as the base, it would be left at ''~~2.13.0~~''.		: This should also be set to the version you will now be working on. Since, in this example, we are moving to a Fedora 20 base, it should be set to ''20''. Had we decided to continue using Fedora 18 as the base, it would be left at ''18''.

Paul Blankenbaker at 18:49, 25 January 2011

2011-01-25T18:49:26Z

← Older revision		Revision as of 14:49, 25 January 2011
Line 1:		Line 1:
	This step is not typically required when you plan on continuing work in the same major release area. For example, if you just produced a ''2.13.0'' release and expect to continue supporting it and possibly having more ''2.13.0'' maintenance releases, you will likely ''not need'' to update the variables mentioned below.		This step is not typically required when you plan on continuing work in the same major release area. For example, if you just produced a ''2.13.0'' release and expect to continue supporting it and possibly having more ''2.13.0'' maintenance releases, you will likely ''not need'' to update the variables mentioned below.

	~~You~~ should ~~inspect/~~change the value of the RELEASE, RELEASE_LAST~~, RELEASE_LAST_PREV and RELEASE_NEXT~~ variables at the top of the include/data/configure.in script to their logical values.		If necessary, you should change the value of the RELEASE and/or RELEASE_LAST variables at the top of the include/data/configure.in script to their logical values.

	The following assumes that you just ~~created the~~ ''2.11.0'' release and ~~the last release published was ''1.8.1''.~~		The following assumes that you just published a ''2.13.0'' release and are now planning on moving to a Fedora 15 base.

	~~; RELEASE_LAST_PREV~~
	~~: This should be set to the version of the release prior to the one you just created. For example, if you just released ''2.11.0'' and the prior release was ''1.8.1'' then set RELEASE_LAST_PREV~~ to ~~''1.8.1''~~.

	; RELEASE_LAST		; RELEASE_LAST
	: This should be set to the version just released (''2.11.0'' in this example).		: This should be set to the version just released (''2.13.0'' in this example).

	; RELEASE		; RELEASE
	: This should also be set to the version ~~just released (''2~~.~~11.0''~~ in this example~~). This is new starting with ''2.11.0'' where~~ we ~~continue supporting the release via yum updates until the next release of~~ Fedora.		: This should also be set to the version you will now be working on. Since, in this example, we are moving to a Fedora 15 base, it should be set to ''2.15.0''. Had we decided to continue using Fedora 13 as the base, it would be left at ''2.13.0''.

	~~; RELEASE_NEXT~~
	~~: This~~ should be ~~a guess at what the next release will be. It will be formed by NST's major ID (2), followed by the version of Fedora we expect~~ to ~~base it off of. For example, if the current release is~~ ''2.11.0'' ~~(based off of~~ Fedora ~~11)~~, ~~a reasonable guess for RELEASE_NEXT~~ would be ''2.12.0'' ~~(assuming the next release will be based off of Fedora 12)~~.

Paul Blankenbaker at 18:26, 25 January 2011

2011-01-25T18:26:25Z

← Older revision		Revision as of 14:26, 25 January 2011
Line 16:		Line 16:
	; RELEASE_NEXT		; RELEASE_NEXT
	: This should be a guess at what the next release will be. It will be formed by NST's major ID (2), followed by the version of Fedora we expect to base it off of. For example, if the current release is ''2.11.0'' (based off of Fedora 11), a reasonable guess for RELEASE_NEXT would be ''2.12.0'' (assuming the next release will be based off of Fedora 12).		: This should be a guess at what the next release will be. It will be formed by NST's major ID (2), followed by the version of Fedora we expect to base it off of. For example, if the current release is ''2.11.0'' (based off of Fedora 11), a reasonable guess for RELEASE_NEXT would be ''2.12.0'' (assuming the next release will be based off of Fedora 12).


	~~Here are a few more variables you may need to adjust in the file:~~

	~~; MANIFEST_FILES~~
	: You probably won't need to change this, however, if you plan on change the number of variations of the NST to distribute, you will want to update this list (you will also need to update the release: target in include/make/makefile if you add, remove or modify your variant list).

Paul Blankenbaker at 18:20, 25 January 2011

2011-01-25T18:20:26Z

← Older revision		Revision as of 14:20, 25 January 2011
Line 22:		Line 22:
	; MANIFEST_FILES		; MANIFEST_FILES
	: You probably won't need to change this, however, if you plan on change the number of variations of the NST to distribute, you will want to update this list (you will also need to update the release: target in include/make/makefile if you add, remove or modify your variant list).		: You probably won't need to change this, however, if you plan on change the number of variations of the NST to distribute, you will want to update this list (you will also need to update the release: target in include/make/makefile if you add, remove or modify your variant list).

	~~; RELEASE_LAST_MD5~~
	: You should change this to the MD5 checksum associated with the ''nst-${VERSION}/nst-${VERSION}.${HWARCH}.iso'' file. You can find this value near the top of include/manifest/release-${VERSION}.${HWARCH}.xml. This variable is used in the documentation for examples of verifying the MD5 checksum (things will still work if you don't update it, but users may be irritated if they get different results when following documentation examples).

Paul Blankenbaker at 08:58, 21 January 2011

2011-01-21T08:58:07Z

← Older revision		Revision as of 04:58, 21 January 2011
Line 1:		Line 1:
	~~Update RELEASE~~		This step is not typically required when you plan on continuing work in the same major release area. For example, if you just produced a ''2.13.0'' release and expect to continue supporting it and possibly having more ''2.13.0'' maintenance releases, you will likely ''not need'' to update the variables mentioned below.

	You should ~~immediately~~ inspect/change the value of the RELEASE, RELEASE_LAST, RELEASE_LAST_PREV and RELEASE_NEXT variables at the top of the include/data/configure.in script to their logical values.		You should inspect/change the value of the RELEASE, RELEASE_LAST, RELEASE_LAST_PREV and RELEASE_NEXT variables at the top of the include/data/configure.in script to their logical values.

	The following assumes that you just created the ''2.11.0'' release and the last release published was ''1.8.1''.		The following assumes that you just created the ''2.11.0'' release and the last release published was ''1.8.1''.

Paul Blankenbaker at 22:37, 18 October 2009

2009-10-18T22:37:14Z

← Older revision		Revision as of 18:37, 18 October 2009
Line 25:		Line 25:
	; RELEASE_LAST_MD5		; RELEASE_LAST_MD5
	: You should change this to the MD5 checksum associated with the ''nst-${VERSION}/nst-${VERSION}.${HWARCH}.iso'' file. You can find this value near the top of include/manifest/release-${VERSION}.${HWARCH}.xml. This variable is used in the documentation for examples of verifying the MD5 checksum (things will still work if you don't update it, but users may be irritated if they get different results when following documentation examples).		: You should change this to the MD5 checksum associated with the ''nst-${VERSION}/nst-${VERSION}.${HWARCH}.iso'' file. You can find this value near the top of include/manifest/release-${VERSION}.${HWARCH}.xml. This variable is used in the documentation for examples of verifying the MD5 checksum (things will still work if you don't update it, but users may be irritated if they get different results when following documentation examples).

	Finally, locate the '''release-tag''' target in the file ''include/make/makefile'' and update it to make sure that '''make release-tag''' check will fail (so you don't accidentally re-tag the CVS source files).

Paul Blankenbaker: New page: Update RELEASE You should immediately inspect/change the value of the RELEASE, RELEASE_LAST, RELEASE_LAST_PREV and RELEASE_NEXT variables at the top of the include/data/configure.in scrip...

2009-09-22T16:48:04Z

New page: Update RELEASE You should immediately inspect/change the value of the RELEASE, RELEASE_LAST, RELEASE_LAST_PREV and RELEASE_NEXT variables at the top of the include/data/configure.in scrip...

New page

Update RELEASE

You should immediately inspect/change the value of the RELEASE, RELEASE_LAST, RELEASE_LAST_PREV and RELEASE_NEXT variables at the top of the include/data/configure.in script to their logical values.

The following assumes that you just created the ''2.11.0'' release and the last release published was ''1.8.1''.

; RELEASE_LAST_PREV
: This should be set to the version of the release prior to the one you just created. For example, if you just released ''2.11.0'' and the prior release was ''1.8.1'' then set RELEASE_LAST_PREV to ''1.8.1''.

; RELEASE_LAST
: This should be set to the version just released (''2.11.0'' in this example).

; RELEASE
: This should also be set to the version just released (''2.11.0'' in this example). This is new starting with ''2.11.0'' where we continue supporting the release via yum updates until the next release of Fedora.

; RELEASE_NEXT
: This should be a guess at what the next release will be. It will be formed by NST's major ID (2), followed by the version of Fedora we expect to base it off of. For example, if the current release is ''2.11.0'' (based off of Fedora 11), a reasonable guess for RELEASE_NEXT would be ''2.12.0'' (assuming the next release will be based off of Fedora 12).

Here are a few more variables you may need to adjust in the file:

; MANIFEST_FILES
: You probably won't need to change this, however, if you plan on change the number of variations of the NST to distribute, you will want to update this list (you will also need to update the release: target in include/make/makefile if you add, remove or modify your variant list).

; RELEASE_LAST_MD5
: You should change this to the MD5 checksum associated with the ''nst-${VERSION}/nst-${VERSION}.${HWARCH}.iso'' file. You can find this value near the top of include/manifest/release-${VERSION}.${HWARCH}.xml. This variable is used in the documentation for examples of verifying the MD5 checksum (things will still work if you don't update it, but users may be irritated if they get different results when following documentation examples).

Finally, locate the '''release-tag''' target in the file ''include/make/makefile'' and update it to make sure that '''make release-tag''' check will fail (so you don't accidentally re-tag the CVS source files).