Re: Coming Soon: Stable D Releases!
On 2012-07-16 09:51, Adam Wilson wrote: As a result of the D Versioning thread, we have decided to create a new organization on Github called dlang-stable. This organization will be responsible for maintaining stable releases of DMD, DRuntime, and Phobos. So what is a stable release? A stable release is a complete build of DMD, DRuntime, and Phobos that ONLY includes the latest bug-fixes and non-breaking enhancements to existing features. It will not include, new features, breaking enhancements, and any other code that the core development team may be working on. How often will you release? The goal of this project is that D is stable at all times. Therefore, our primary method of release will simply be Git-HEAD. However, we will also make available frequent packaged distributions for those who may be unable to use Git-HEAD. While the exact release cadence is to be determined, we expect it to be more frequent then the current release schedule. What if a bug fix breaks my code? We will still issue the fix. Fixing the broken behavior is more important than allowing broken code to continue. How much will the core team be involved? The idea behind this project is that the core team needs to focus on developing D as fast as possible. However, we will coordinate with them as necessary when it is time to pull in the latest work from the development repositories and as any conflicts arise to between the two codebases. Is this a fork of D? No. Our goal is to follow the development of D perfectly. All the code for the stable releases will be received from the primary repositories. We will simply be cherry-picking the commits we want in the release. Will new features ever be merged from the primary repositories? Yes. As new features mature, they will be pulled into the stable repos. Precisely when this happens will be a mutual decision by all the developers involved and the community at large. I have a bug fix ready to go. Who do I send the pull request to? Please send all pull requests to the primary development repositories (D-Programming-Language). From there we will incorporate your fixes as they are merged into the primary repositories. I still want to hack on DMD/DRuntme/Phobos. Where do I point my local repositories? Then nothing will change for you. You can keep all your existing remotes. Who is developing this project? For the moment, just myself, with support from Andrei. Although, it would be much appreciated if a few others would step forward as release maintainers to help with the bug fix merges and quality control. If you are interested, I would love to hear from you. You can reply here, send me an email, or contact me on GitHub (handle: LightBender). OK, I'm sold! When will the first Stable release be ready? Not until after the official release of 2.060. We feel that it is best to this project from a released build of DMD and from then on maintain the stable versions. While it is technically feasible to go back and start from 2.059, the number of bug fixes since then it would make it a gargantuan task. In addition, this period allows us to build-up the release team, synchronize with the core team, and polish our release procedures. After 2.060 we will begin releasing stable versions of D Where can I find these stable releases? The stable releases are located on GitHub at https://github.com/dlang-stable Once the packaged release become available you can expect to see them on http://www.dlang.org/ If you have any more questions or comments, please reply below and will attempt to answer them to the best of my ability. Thank you for reading and I hope you enjoy D's new Stable releases! Thanks for properly announcing this. Question: are the going to be release only from "dlang-stable" or from the current repositories as well. -- /Jacob Carlborg
Re: Coming Soon: Stable D Releases!
On Monday, 16 July 2012 at 07:51:16 UTC, Adam Wilson wrote: As a result of the D Versioning thread, we have decided to create a new organization on Github called dlang-stable. This organization will be responsible for maintaining stable releases of DMD, DRuntime, and Phobos. Congratulations! I also proposed this idea: Also, nobody is preventing any person that considers this to be very important from creating a fork of stable branch and applying bug-fixes there. If this happens to be a very useful option, then it could be accepted as a policy. So my point of view is that it might be too early to have such policy yet. http://forum.dlang.org/post/ovtazudocniqfcwzx...@forum.dlang.org Also I propose to have a download page with tracking statistics. This would be a nice feedback tool for multiple purposes.
Re: Coming Soon: Stable D Releases!
Adam Wilson, el 16 de July a las 00:51 me escribiste: > As a result of the D Versioning thread, we have decided to create a > new organization on Github called dlang-stable. This organization > will be responsible for maintaining stable releases of DMD, > DRuntime, and Phobos. What will be the version scheme of this dlang-stable compiler? If the git master branch will be the "release", will you increase that version number on each and every commit? I think it would be a good idea to make real releases, with rc and everything to minimize the chances of introducing (untested) regressions (bare in mind that a lot of patches will not merge cleanly so knowing that the original patch introduced no regressions in the devel compiler doesn't mean it will be the same when merged in the stable one). That said, I think it was about time D separate devel from stable, so thanks for stepping forward :) -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Soy como una mosca, parada en el agua. Y vos sos un transatlántico, querés nadar a mi lado. Y me estás ahogando.
Re: Coming Soon: Stable D Releases!
On Monday, 16 July 2012 at 07:51:16 UTC, Adam Wilson wrote: As a result of the D Versioning thread, we have decided to create a new organization on Github called dlang-stable. This organization will be responsible for maintaining stable releases of DMD, DRuntime, and Phobos. For the time being, I'd rather be explicit about who we is, and that this is not an »official« (whatever this really means) endeavor yet. Don't get me wrong, the idea is indeed nice, and probably it will work out just well. I only doubt that it is a good idea to raise expectations too high at this point… David
Re: Coming Soon: Stable D Releases!
Am Mon, 16 Jul 2012 00:51:16 -0700 schrieb "Adam Wilson" : For the 2.059 release I waited a while until apparent regressions and oddities in Phobos (deprecation warnings) were fixed in the main repository before updating the dmd package for Gentoo. This was quite a bit of manual work collecting, applying and testing patches from GitHub and the bug tracker. Will this project be an option for me as a package maintainer? What I need is basically the official dmd zip file (sources, html docs, man pages, bash completion, rdmd binary & co.), but with hotfixes applied at about a week or two after release. It seems like your work could make this possible and also allow me to issue a new revision of the package in case of, say a security fix that comes a month after release. Last not least, will we get notified about critical/important fixes in the "stable" branch? 'Cause polling is so old-school ;). RSS, news group, email, phone call, anything will do. It looks like GitHub has a commit-RSS-feed, but it would be very noisy on most repositories with messages like "forgot this in last check-in" or "deleted unused file/code", and not every commit warrants a new package. As it shows, the beta phase doesn't always catch all regressions in people's code, so I encourage you to do this project and eventually it will be used by GDC and other major from-source projects. By the way: Should this also later become the base for the official zip file download? IIRC Walter wanted to keep track of the DMD downloads from the main web site (no redistribution) and hotfixed versions of D could become increasingly popular. -- Marco
Re: Coming Soon: Stable D Releases!
On 16 July 2012 14:00, Marco Leise wrote: > Am Mon, 16 Jul 2012 00:51:16 -0700 > schrieb "Adam Wilson" : > > As it shows, the beta phase doesn't always catch all regressions in people's > code, so I encourage you to do this project and eventually it will be used by > GDC and other major from-source projects. By the way: Should this also later > become the base for the official zip file download? IIRC Walter wanted to > keep track of the DMD downloads from the main web site (no redistribution) > and hotfixed versions of D could become increasingly popular. > > -- > Marco > And what benefits would GDC get from opting to use this rather than the normal releases? -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Re: Coming Soon: Stable D Releases!
Am Mon, 16 Jul 2012 17:21:39 +0100 schrieb Iain Buclaw : > On 16 July 2012 14:00, Marco Leise wrote: > > Am Mon, 16 Jul 2012 00:51:16 -0700 > > schrieb "Adam Wilson" : > > > > As it shows, the beta phase doesn't always catch all regressions in > > people's code, so I encourage you to do this project and eventually it will > > be used by GDC and other major from-source projects. By the way: Should > > this also later become the base for the official zip file download? IIRC > > Walter wanted to keep track of the DMD downloads from the main web site (no > > redistribution) and hotfixed versions of D could become increasingly > > popular. > > > > -- > > Marco > > > > And what benefits would GDC get from opting to use this rather than > the normal releases? What he said, [regression] fixes that didn't make it into the initial release. I don't know about GDC's 'patch level', but for 2.059 I applied patches for the following issues after release, to have it feel as solid as good old 2.058: - issue-7907 - issue-7911 - issue-7922 - outOfMemoryError-undeprecation - std-path-sep-deprecation In case crypto algorithms become part of Phobos, some patches may improve security as well. Didn't you say you work only with the GitHub release tags for stability? -- Marco
Re: Coming Soon: Stable D Releases!
On 7/16/12 3:51 AM, Adam Wilson wrote: As a result of the D Versioning thread, we have decided to create a new organization on Github called dlang-stable. This organization will be responsible for maintaining stable releases of DMD, DRuntime, and Phobos. [snip] Thank you for reading and I hope you enjoy D's new Stable releases! This is a wonderful initiative that I hope will catch on. Walter and I are fully behind this experiment. We will make/accept changes to the download pages to take into account this new branch. The main threat I see is bugfixes that depend on code previously introduced with now features. I'm not sure how frequent that situation is. Finally, one suggestion: I suggest you relentlessly work to automate the process to the point where you issue e.g. the command ./merge 534d44c979 70dcb958ea and the script merges in the two specified commits, builds everything, runs the test suite, runs the Phobos unittests, and if all worked, builds packages and uploads them making them available right away. That way the team members (busy professionals with many other responsibilities) know that once the collective decision to merge a commit has been taken, there's virtually no overhead to deploying the decision. I'm a huge fan of automation and I believe we've made progress introducing it in dmd's process, but not as much as we could and should. Good luck! Andrei
Re: Coming Soon: Stable D Releases!
On Mon, 16 Jul 2012 06:00:02 -0700, Marco Leise wrote: Am Mon, 16 Jul 2012 00:51:16 -0700 schrieb "Adam Wilson" : For the 2.059 release I waited a while until apparent regressions and oddities in Phobos (deprecation warnings) were fixed in the main repository before updating the dmd package for Gentoo. This was quite a bit of manual work collecting, applying and testing patches from GitHub and the bug tracker. Will this project be an option for me as a package maintainer? What I need is basically the official dmd zip file (sources, html docs, man pages, bash completion, rdmd binary & co.), but with hotfixes applied at about a week or two after release. It seems like your work could make this possible and also allow me to issue a new revision of the package in case of, say a security fix that comes a month after release. Last not least, will we get notified about critical/important fixes in the "stable" branch? 'Cause polling is so old-school ;). RSS, news group, email, phone call, anything will do. It looks like GitHub has a commit-RSS-feed, but it would be very noisy on most repositories with messages like "forgot this in last check-in" or "deleted unused file/code", and not every commit warrants a new package. As it shows, the beta phase doesn't always catch all regressions in people's code, so I encourage you to do this project and eventually it will be used by GDC and other major from-source projects. By the way: Should this also later become the base for the official zip file download? IIRC Walter wanted to keep track of the DMD downloads from the main web site (no redistribution) and hotfixed versions of D could become increasingly popular. For the first few packaged releases we aren't going to call this thing official. It's just an experiment for the moment. But if it is popular and the stability promises we are attempting to make actually hold up, (i.e. this experiment actually works) there are plans to revisit this question with an eye towards making it official. However, since the commit list will be bug-fixes and non-breaking enhancements only, you may find it easier to work off this list than HEAD. If you have any more questions on this subject please email Andrei. (You can find his email at http://erdani.com/index.php/contact/) He is the liaison between this project and the core team. -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Re: Coming Soon: Stable D Releases!
On Monday, 16 July 2012 at 16:39:45 UTC, Marco Leise wrote: Am Mon, 16 Jul 2012 17:21:39 +0100 schrieb Iain Buclaw : On 16 July 2012 14:00, Marco Leise wrote: > Am Mon, 16 Jul 2012 00:51:16 -0700 > schrieb "Adam Wilson" : > > As it shows, the beta phase doesn't always catch all > regressions in people's code, so I encourage you to do this > project and eventually it will be used by GDC and other > major from-source projects. By the way: Should this also > later become the base for the official zip file download? > IIRC Walter wanted to keep track of the DMD downloads from > the main web site (no redistribution) and hotfixed versions > of D could become increasingly popular. > > -- > Marco > And what benefits would GDC get from opting to use this rather than the normal releases? What he said, [regression] fixes that didn't make it into the initial release. I don't know about GDC's 'patch level', but for 2.059 I applied patches for the following issues after release, to have it feel as solid as good old 2.058: - issue-7907 - issue-7911 - issue-7922 - outOfMemoryError-undeprecation - std-path-sep-deprecation In case crypto algorithms become part of Phobos, some patches may improve security as well. Didn't you say you work only with the GitHub release tags for stability? So if I were to represent a theoretical merge sequence in ascii: ... former releases ... DMD Development GDC Development > DMD 2.060 release > | | DMD Development DMD 2.060.1 release v v | | | DMD 2.060.2 release | v | | | DMD 2.060.3 release | v | | DMD 2.061 beta DMD 2.060.4 release v v | | DMD 2.061 RCDMD 2.060.5 release v v | | >-- DMD 2.061 release --> Would this be a correct way of utilising this new process? I use Github release tags so I get the correct test suite for the release I'm merging in. Other than that the only other special information you need to know is that I use meld to sync the frontend and library sources together. Regards Iain
Re: Coming Soon: Stable D Releases!
On Mon, 16 Jul 2012 09:21:39 -0700, Iain Buclaw wrote: On 16 July 2012 14:00, Marco Leise wrote: Am Mon, 16 Jul 2012 00:51:16 -0700 schrieb "Adam Wilson" : As it shows, the beta phase doesn't always catch all regressions in people's code, so I encourage you to do this project and eventually it will be used by GDC and other major from-source projects. By the way: Should this also later become the base for the official zip file download? IIRC Walter wanted to keep track of the DMD downloads from the main web site (no redistribution) and hotfixed versions of D could become increasingly popular. -- Marco And what benefits would GDC get from opting to use this rather than the normal releases? The main benefit I could see is the faster cycle focusing on bugs. I don't know what GCC's release cycle is (something tells me it's pretty glacial), but for any users of your Git-HEAD code, the bug fixes could certainly appear faster. The drawback is that new features may not appear as quickly because we will want them to stabilize before we roll them in. As to whether or not you use it, that's up to you. Our goal with this experiment is to build highly reliable (stable) releases on a quicker cycle so that we can fix bugs faster. If you think GDC could benefit from that, you are welcome to base GDC off these packages. -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Re: Coming Soon: Stable D Releases!
On 16 July 2012 18:31, Adam Wilson wrote: > On Mon, 16 Jul 2012 09:21:39 -0700, Iain Buclaw wrote: > >> On 16 July 2012 14:00, Marco Leise wrote: >>> >>> Am Mon, 16 Jul 2012 00:51:16 -0700 >>> schrieb "Adam Wilson" : >>> >>> As it shows, the beta phase doesn't always catch all regressions in >>> people's code, so I encourage you to do this project and eventually it will >>> be used by GDC and other major from-source projects. By the way: Should this >>> also later become the base for the official zip file download? IIRC Walter >>> wanted to keep track of the DMD downloads from the main web site (no >>> redistribution) and hotfixed versions of D could become increasingly >>> popular. >>> >>> -- >>> Marco >>> >> >> And what benefits would GDC get from opting to use this rather than >> the normal releases? >> > > The main benefit I could see is the faster cycle focusing on bugs. I don't > know what GCC's release cycle is (something tells me it's pretty glacial), > but for any users of your Git-HEAD code, the bug fixes could certainly > appear faster. > It's roughly once a year, maybe a little less. Depends on regressions, open bugs, etc. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Re: Coming Soon: Stable D Releases!
Good thing that this is an experiment because creating a new organization just for something like this is a stupid idea. Is it so difficult to create branches and use the features that git provides?!?
Re: Coming Soon: Stable D Releases!
On Mon, 16 Jul 2012 02:59:31 -0700, David Nadlinger wrote: On Monday, 16 July 2012 at 07:51:16 UTC, Adam Wilson wrote: As a result of the D Versioning thread, we have decided to create a new organization on Github called dlang-stable. This organization will be responsible for maintaining stable releases of DMD, DRuntime, and Phobos. For the time being, I'd rather be explicit about who we is, and that this is not an »official« (whatever this really means) endeavor yet. Don't get me wrong, the idea is indeed nice, and probably it will work out just well. I only doubt that it is a good idea to raise expectations too high at this point… David It's not official, yet. But it does have the backing of the Walter and Andrei. So if this experiment is successful then it will likely be made official. And you guys can help make it successful by supporting it. And it needs all the help it can get! I am just one guy who has to work for a living. :-) -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Re: Coming Soon: Stable D Releases!
On Mon, 16 Jul 2012 10:26:31 -0700, Iain Buclaw wrote: On Monday, 16 July 2012 at 16:39:45 UTC, Marco Leise wrote: Am Mon, 16 Jul 2012 17:21:39 +0100 schrieb Iain Buclaw : On 16 July 2012 14:00, Marco Leise wrote: > Am Mon, 16 Jul 2012 00:51:16 -0700 > schrieb "Adam Wilson" : > > As it shows, the beta phase doesn't always catch all > regressions in people's code, so I encourage you to do this > project and eventually it will be used by GDC and other > major from-source projects. By the way: Should this also > later become the base for the official zip file download? > IIRC Walter wanted to keep track of the DMD downloads from > the main web site (no redistribution) and hotfixed versions > of D could become increasingly popular. > > -- > Marco > And what benefits would GDC get from opting to use this rather than the normal releases? What he said, [regression] fixes that didn't make it into the initial release. I don't know about GDC's 'patch level', but for 2.059 I applied patches for the following issues after release, to have it feel as solid as good old 2.058: - issue-7907 - issue-7911 - issue-7922 - outOfMemoryError-undeprecation - std-path-sep-deprecation In case crypto algorithms become part of Phobos, some patches may improve security as well. Didn't you say you work only with the GitHub release tags for stability? So if I were to represent a theoretical merge sequence in ascii: ... former releases ... DMD Development GDC Development > DMD 2.060 release > | | DMD Development DMD 2.060.1 release v v | | | DMD 2.060.2 release | v | | | DMD 2.060.3 release | v | | DMD 2.061 beta DMD 2.060.4 release v v | | DMD 2.061 RCDMD 2.060.5 release v v | | >-- DMD 2.061 release --> Would this be a correct way of utilising this new process? I'd say mostly correct. The last step is the one where we might differ though, as we may choose to wait on regression and other bug-fixes to any new features in that release. But we might not wait if the build consists of no new features, just breaking changes to existing ones. It will be more of a conversation with the community about how stable they feel the changes in the latest release are. For example, of the new COFF support is still highly unstable (lots of fix commits), we might wait until that settles down before merging in the entirety of the development repos. So maybe something like: ... former releases ... DMD Development GDC Development > DMD 2.060 release > | | DMD Development DMD 2.060.1 release v v | | | DMD 2.060.2 release | v | | | DMD 2.060.3 release | v | | DMD 2.061 beta DMD 2.060.4 release v v | | DMD 2.061 RCDMD 2.060.5 release v v | | DMD 2.061 release DMD 2.060.6 release v v | | >- DMD 2.061 merge -> However, the precise versioning scheme is something of an open question, and as we gain more experience with this new development model we may modify this. Any feedback on this is quite welcome. All this is going to require some coordination with the core team. I use Github release tags so I get the correct test suite for the release I'm merging in. Other than that the only other special information you need to know is that I use meld to sync the frontend and library sources together. Regards Iain -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Re: Coming Soon: Stable D Releases!
On Mon, 16 Jul 2012 01:56:23 -0700, Leandro Lucarella wrote: Adam Wilson, el 16 de July a las 00:51 me escribiste: As a result of the D Versioning thread, we have decided to create a new organization on Github called dlang-stable. This organization will be responsible for maintaining stable releases of DMD, DRuntime, and Phobos. What will be the version scheme of this dlang-stable compiler? If the git master branch will be the "release", will you increase that version number on each and every commit? We will probably only bump the version number for packaged releases. Anything else is going to be a lot of relatively useless wheel-spinning. I think it would be a good idea to make real releases, with rc and everything to minimize the chances of introducing (untested) regressions (bare in mind that a lot of patches will not merge cleanly so knowing that the original patch introduced no regressions in the devel compiler doesn't mean it will be the same when merged in the stable one). One option to help alleviate this concern is to do the initial cherry-pick on a separate branch and merge it in once it passes the unittests. This is a benefit of using a separate GitHub organization. That said, I think it was about time D separate devel from stable, so thanks for stepping forward :) You're welcome! -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Soy como una mosca, parada en el agua. Y vos sos un transatlántico, querés nadar a mi lado. Y me estás ahogando. -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Re: Coming Soon: Stable D Releases!
On Mon, 16 Jul 2012 01:14:40 -0700, Jacob Carlborg wrote: On 2012-07-16 09:51, Adam Wilson wrote: As a result of the D Versioning thread, we have decided to create a new organization on Github called dlang-stable. This organization will be responsible for maintaining stable releases of DMD, DRuntime, and Phobos. So what is a stable release? A stable release is a complete build of DMD, DRuntime, and Phobos that ONLY includes the latest bug-fixes and non-breaking enhancements to existing features. It will not include, new features, breaking enhancements, and any other code that the core development team may be working on. How often will you release? The goal of this project is that D is stable at all times. Therefore, our primary method of release will simply be Git-HEAD. However, we will also make available frequent packaged distributions for those who may be unable to use Git-HEAD. While the exact release cadence is to be determined, we expect it to be more frequent then the current release schedule. What if a bug fix breaks my code? We will still issue the fix. Fixing the broken behavior is more important than allowing broken code to continue. How much will the core team be involved? The idea behind this project is that the core team needs to focus on developing D as fast as possible. However, we will coordinate with them as necessary when it is time to pull in the latest work from the development repositories and as any conflicts arise to between the two codebases. Is this a fork of D? No. Our goal is to follow the development of D perfectly. All the code for the stable releases will be received from the primary repositories. We will simply be cherry-picking the commits we want in the release. Will new features ever be merged from the primary repositories? Yes. As new features mature, they will be pulled into the stable repos. Precisely when this happens will be a mutual decision by all the developers involved and the community at large. I have a bug fix ready to go. Who do I send the pull request to? Please send all pull requests to the primary development repositories (D-Programming-Language). From there we will incorporate your fixes as they are merged into the primary repositories. I still want to hack on DMD/DRuntme/Phobos. Where do I point my local repositories? Then nothing will change for you. You can keep all your existing remotes. Who is developing this project? For the moment, just myself, with support from Andrei. Although, it would be much appreciated if a few others would step forward as release maintainers to help with the bug fix merges and quality control. If you are interested, I would love to hear from you. You can reply here, send me an email, or contact me on GitHub (handle: LightBender). OK, I'm sold! When will the first Stable release be ready? Not until after the official release of 2.060. We feel that it is best to this project from a released build of DMD and from then on maintain the stable versions. While it is technically feasible to go back and start from 2.059, the number of bug fixes since then it would make it a gargantuan task. In addition, this period allows us to build-up the release team, synchronize with the core team, and polish our release procedures. After 2.060 we will begin releasing stable versions of D Where can I find these stable releases? The stable releases are located on GitHub at https://github.com/dlang-stable Once the packaged release become available you can expect to see them on http://www.dlang.org/ If you have any more questions or comments, please reply below and will attempt to answer them to the best of my ability. Thank you for reading and I hope you enjoy D's new Stable releases! Thanks for properly announcing this. Question: are the going to be release only from "dlang-stable" or from the current repositories as well. For the moment both. This is just an experimental project. And most projects with stable and development branches release from both. I see no reason not to continue releasing from DEV as well as STABLE. Pick your poison. :) -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Re: Coming Soon: Stable D Releases!
On Mon, 16 Jul 2012 10:51:59 -0700, Caligo wrote: Good thing that this is an experiment because creating a new organization just for something like this is a stupid idea. Is it so difficult to create branches and use the features that git provides?!? Walter was very uneasy about opening up the primary DMD repo in that manner. Maybe if this experiment proves successful he will be more open to allowing the work to take place in the primary repo? Let's make this project successful and show Walter the true power of Git! -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Re: Coming Soon: Stable D Releases!
On 16 July 2012 18:56, Adam Wilson wrote: > On Mon, 16 Jul 2012 10:26:31 -0700, Iain Buclaw wrote: > >> On Monday, 16 July 2012 at 16:39:45 UTC, Marco Leise wrote: >>> >>> Am Mon, 16 Jul 2012 17:21:39 +0100 >>> schrieb Iain Buclaw : >>> On 16 July 2012 14:00, Marco Leise wrote: > Am Mon, 16 Jul 2012 00:51:16 -0700 > schrieb "Adam Wilson" : > > As it shows, the beta phase doesn't always catch all > regressions in > people's code, so I encourage you to do this > project and eventually it > will be used by GDC and other > major from-source projects. By the way: > Should this also > later become the base for the official zip file > download? > > IIRC Walter wanted to keep track of the DMD downloads from > the main > > web > site (no redistribution) and hotfixed versions > of D could become > increasingly popular. > > -- > Marco > And what benefits would GDC get from opting to use this rather than the normal releases? >>> >>> >>> What he said, [regression] fixes that didn't make it into the initial >>> release. I don't know about GDC's 'patch level', but for 2.059 I applied >>> patches for the following issues after release, to have it feel as solid as >>> good old 2.058: >>> - issue-7907 >>> - issue-7911 >>> - issue-7922 >>> - outOfMemoryError-undeprecation >>> - std-path-sep-deprecation >>> >>> In case crypto algorithms become part of Phobos, some patches may improve >>> security as well. Didn't you say you work only with the GitHub release tags >>> for stability? >> >> >> So if I were to represent a theoretical merge sequence in ascii: >> >> ... former releases ... >> DMD Development GDC Development >> > DMD 2.060 release > >> | | >> DMD Development DMD 2.060.1 release >> v v >> | | >> | DMD 2.060.2 release >> | v >> | | >> | DMD 2.060.3 release >> | v >> | | >> DMD 2.061 beta DMD 2.060.4 release >> v v >> | | >> DMD 2.061 RCDMD 2.060.5 release >> v v >> | | >> >-- DMD 2.061 release --> >> >> >> Would this be a correct way of utilising this new process? >> > > I'd say mostly correct. The last step is the one where we might differ > though, as we may choose to wait on regression and other bug-fixes to any > new features in that release. But we might not wait if the build consists of > no new features, just breaking changes to existing ones. It will be more of > a conversation with the community about how stable they feel the changes in > the latest release are. For example, of the new COFF support is still highly > unstable (lots of fix commits), we might wait until that settles down before > merging in the entirety of the development repos. > And how does DMD backend support for COFF affect GDC? :-) -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Re: Coming Soon: Stable D Releases!
On Monday, 16 July 2012 at 07:51:16 UTC, Adam Wilson wrote: As a result of the D Versioning thread, we have decided to create a new organization on Github called dlang-stable. This organization will be responsible for maintaining stable releases of DMD, DRuntime, and Phobos. So what is a stable release? A stable release is a complete build of DMD, DRuntime, and Phobos that ONLY includes the latest bug-fixes and non-breaking enhancements to existing features. It will not include, new features, breaking enhancements, and any other code that the core development team may be working on. How often will you release? The goal of this project is that D is stable at all times. Therefore, our primary method of release will simply be Git-HEAD. However, we will also make available frequent packaged distributions for those who may be unable to use Git-HEAD. While the exact release cadence is to be determined, we expect it to be more frequent then the current release schedule. What if a bug fix breaks my code? We will still issue the fix. Fixing the broken behavior is more important than allowing broken code to continue. How much will the core team be involved? The idea behind this project is that the core team needs to focus on developing D as fast as possible. However, we will coordinate with them as necessary when it is time to pull in the latest work from the development repositories and as any conflicts arise to between the two codebases. Is this a fork of D? No. Our goal is to follow the development of D perfectly. All the code for the stable releases will be received from the primary repositories. We will simply be cherry-picking the commits we want in the release. Will new features ever be merged from the primary repositories? Yes. As new features mature, they will be pulled into the stable repos. Precisely when this happens will be a mutual decision by all the developers involved and the community at large. I have a bug fix ready to go. Who do I send the pull request to? Please send all pull requests to the primary development repositories (D-Programming-Language). From there we will incorporate your fixes as they are merged into the primary repositories. I still want to hack on DMD/DRuntme/Phobos. Where do I point my local repositories? Then nothing will change for you. You can keep all your existing remotes. Who is developing this project? For the moment, just myself, with support from Andrei. Although, it would be much appreciated if a few others would step forward as release maintainers to help with the bug fix merges and quality control. If you are interested, I would love to hear from you. You can reply here, send me an email, or contact me on GitHub (handle: LightBender). OK, I'm sold! When will the first Stable release be ready? Not until after the official release of 2.060. We feel that it is best to this project from a released build of DMD and from then on maintain the stable versions. While it is technically feasible to go back and start from 2.059, the number of bug fixes since then it would make it a gargantuan task. In addition, this period allows us to build-up the release team, synchronize with the core team, and polish our release procedures. After 2.060 we will begin releasing stable versions of D Where can I find these stable releases? The stable releases are located on GitHub at https://github.com/dlang-stable Once the packaged release become available you can expect to see them on http://www.dlang.org/ If you have any more questions or comments, please reply below and will attempt to answer them to the best of my ability. Thank you for reading and I hope you enjoy D's new Stable releases! Even though I've said this to you in IRC, I'll share here publicly that I think this should really be done on a branch in the main repo[1]. This setup seems overly complicated and confusing (though I recognize you are just working with limitations imposed upon you). I'd like to propose an alternative to this cherry-picking solution though which is much easier and plays to git's strengths. 1. Features would be pull requests targeting D-P-L/dmd:master. Walter could still push his features directly. 2. Bugfixes would be pull requests targeting D-P-L/dmd:stable. Walter could still push his bugfixes directly. 3. D-P-L/dmd:master would periodically merge D-P-L/dmd:stable to pull bug fixes in. This setup requires almost no changes by all contributors. Here is a mini guide for contributors outlining the slightly changed workflow. Working on a bugfix: 1. git checkout -b issue-555 stable 2. ... hack hack hack commit ... 3. git push origin issue-555 (Walter can just do `git push origin stable` and skip step 4, assuming origin is D-P-L) 4. Make pull request targeting stable (most people already do this but branch from master) Working on a feature: 1. git checkout -b constpocalypse master 2. ... hack hack hack commi
Re: Coming Soon: Stable D Releases!
On Mon, 16 Jul 2012 01:29:35 -0700, Roman D. Boiko wrote: On Monday, 16 July 2012 at 07:51:16 UTC, Adam Wilson wrote: As a result of the D Versioning thread, we have decided to create a new organization on Github called dlang-stable. This organization will be responsible for maintaining stable releases of DMD, DRuntime, and Phobos. Congratulations! I also proposed this idea: Also, nobody is preventing any person that considers this to be very important from creating a fork of stable branch and applying bug-fixes there. If this happens to be a very useful option, then it could be accepted as a policy. So my point of view is that it might be too early to have such policy yet. http://forum.dlang.org/post/ovtazudocniqfcwzx...@forum.dlang.org That is effectively what we have done here. The dlang-stable repos are forks of the current repos and rely on them for their bug-fix commits. While not everyone agrees that this is the right path, it's the best compromise we could come up with ... and everybody is unhappy, I'd call that a success! ;-) Also I propose to have a download page with tracking statistics. This would be a nice feedback tool for multiple purposes. Andrei has said that he would be willing to provide this support on the website and Walter approves. -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Re: Coming Soon: Stable D Releases!
What?! All he has to do is create a branch and call it stable, or whatever, and use cherry-pick to move small stables patches from other branches to the stable branch. What's so difficult about that? I don't get it. On Mon, Jul 16, 2012 at 1:03 PM, Adam Wilson wrote: > On Mon, 16 Jul 2012 10:51:59 -0700, Caligo wrote: > >> Good thing that this is an experiment because creating a new >> organization just for something like this is a stupid idea. Is it so >> difficult to create branches and use the features that git provides?!? > > > Walter was very uneasy about opening up the primary DMD repo in that manner. > Maybe if this experiment proves successful he will be more open to allowing > the work to take place in the primary repo? Let's make this project > successful and show Walter the true power of Git! > > > -- > Adam Wilson > IRC: LightBender > Project Coordinator > The Horizon Project > http://www.thehorizonproject.org/
Re: Coming Soon: Stable D Releases!
On Mon, 16 Jul 2012 11:12:38 -0700, Iain Buclaw wrote: On 16 July 2012 18:56, Adam Wilson wrote: On Mon, 16 Jul 2012 10:26:31 -0700, Iain Buclaw wrote: On Monday, 16 July 2012 at 16:39:45 UTC, Marco Leise wrote: Am Mon, 16 Jul 2012 17:21:39 +0100 schrieb Iain Buclaw : On 16 July 2012 14:00, Marco Leise wrote: > Am Mon, 16 Jul 2012 00:51:16 -0700 > schrieb "Adam Wilson" : > > As it shows, the beta phase doesn't always catch all > regressions in > people's code, so I encourage you to do this > project and eventually it > will be used by GDC and other > major from-source projects. By the way: > Should this also > later become the base for the official zip file download? > > IIRC Walter wanted to keep track of the DMD downloads from > the main web > site (no redistribution) and hotfixed versions > of D could become > increasingly popular. > > -- > Marco > And what benefits would GDC get from opting to use this rather than the normal releases? What he said, [regression] fixes that didn't make it into the initial release. I don't know about GDC's 'patch level', but for 2.059 I applied patches for the following issues after release, to have it feel as solid as good old 2.058: - issue-7907 - issue-7911 - issue-7922 - outOfMemoryError-undeprecation - std-path-sep-deprecation In case crypto algorithms become part of Phobos, some patches may improve security as well. Didn't you say you work only with the GitHub release tags for stability? So if I were to represent a theoretical merge sequence in ascii: ... former releases ... DMD Development GDC Development > DMD 2.060 release > | | DMD Development DMD 2.060.1 release v v | | | DMD 2.060.2 release | v | | | DMD 2.060.3 release | v | | DMD 2.061 beta DMD 2.060.4 release v v | | DMD 2.061 RCDMD 2.060.5 release v v | | >-- DMD 2.061 release --> Would this be a correct way of utilising this new process? I'd say mostly correct. The last step is the one where we might differ though, as we may choose to wait on regression and other bug-fixes to any new features in that release. But we might not wait if the build consists of no new features, just breaking changes to existing ones. It will be more of a conversation with the community about how stable they feel the changes in the latest release are. For example, of the new COFF support is still highly unstable (lots of fix commits), we might wait until that settles down before merging in the entirety of the development repos. And how does DMD backend support for COFF affect GDC? :-) Very little I imagine. But we are working against DMD. Since you only want the front-end fixes, I imagine that (at least in terms of the backend) you won't care much when we merge that feature. My point was more general to versioning, in that we might update the stable branches to the new release day one. The new fixes will still appear though. Obviously this would have more impact for you with any new front-end features. -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Re: Coming Soon: Stable D Releases!
On Mon, 16 Jul 2012 11:18:55 -0700, Caligo wrote: What?! All he has to do is create a branch and call it stable, or whatever, and use cherry-pick to move small stables patches from other branches to the stable branch. What's so difficult about that? I don't get it. On Mon, Jul 16, 2012 at 1:03 PM, Adam Wilson wrote: On Mon, 16 Jul 2012 10:51:59 -0700, Caligo wrote: Good thing that this is an experiment because creating a new organization just for something like this is a stupid idea. Is it so difficult to create branches and use the features that git provides?!? Walter was very uneasy about opening up the primary DMD repo in that manner. Maybe if this experiment proves successful he will be more open to allowing the work to take place in the primary repo? Let's make this project successful and show Walter the true power of Git! -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/ He already works on D full-time, this would only slow him down. The other option is to open the repos to even more people with master push rights, and it was a months-long struggle to convince him to let Kenji, Brad, and Don push. Imagine the effort it will take to convince him to let someone else in with push rights? This is a step in the process. Should it prove successful we can reopen the organizational discussion, but first, let's just make it work. -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Re: Coming Soon: Stable D Releases!
On Mon, 16 Jul 2012 11:14:07 -0700, Brad Anderson wrote: On Monday, 16 July 2012 at 07:51:16 UTC, Adam Wilson wrote: As a result of the D Versioning thread, we have decided to create a new organization on Github called dlang-stable. This organization will be responsible for maintaining stable releases of DMD, DRuntime, and Phobos. So what is a stable release? A stable release is a complete build of DMD, DRuntime, and Phobos that ONLY includes the latest bug-fixes and non-breaking enhancements to existing features. It will not include, new features, breaking enhancements, and any other code that the core development team may be working on. How often will you release? The goal of this project is that D is stable at all times. Therefore, our primary method of release will simply be Git-HEAD. However, we will also make available frequent packaged distributions for those who may be unable to use Git-HEAD. While the exact release cadence is to be determined, we expect it to be more frequent then the current release schedule. What if a bug fix breaks my code? We will still issue the fix. Fixing the broken behavior is more important than allowing broken code to continue. How much will the core team be involved? The idea behind this project is that the core team needs to focus on developing D as fast as possible. However, we will coordinate with them as necessary when it is time to pull in the latest work from the development repositories and as any conflicts arise to between the two codebases. Is this a fork of D? No. Our goal is to follow the development of D perfectly. All the code for the stable releases will be received from the primary repositories. We will simply be cherry-picking the commits we want in the release. Will new features ever be merged from the primary repositories? Yes. As new features mature, they will be pulled into the stable repos. Precisely when this happens will be a mutual decision by all the developers involved and the community at large. I have a bug fix ready to go. Who do I send the pull request to? Please send all pull requests to the primary development repositories (D-Programming-Language). From there we will incorporate your fixes as they are merged into the primary repositories. I still want to hack on DMD/DRuntme/Phobos. Where do I point my local repositories? Then nothing will change for you. You can keep all your existing remotes. Who is developing this project? For the moment, just myself, with support from Andrei. Although, it would be much appreciated if a few others would step forward as release maintainers to help with the bug fix merges and quality control. If you are interested, I would love to hear from you. You can reply here, send me an email, or contact me on GitHub (handle: LightBender). OK, I'm sold! When will the first Stable release be ready? Not until after the official release of 2.060. We feel that it is best to this project from a released build of DMD and from then on maintain the stable versions. While it is technically feasible to go back and start from 2.059, the number of bug fixes since then it would make it a gargantuan task. In addition, this period allows us to build-up the release team, synchronize with the core team, and polish our release procedures. After 2.060 we will begin releasing stable versions of D Where can I find these stable releases? The stable releases are located on GitHub at https://github.com/dlang-stable Once the packaged release become available you can expect to see them on http://www.dlang.org/ If you have any more questions or comments, please reply below and will attempt to answer them to the best of my ability. Thank you for reading and I hope you enjoy D's new Stable releases! Even though I've said this to you in IRC, I'll share here publicly that I think this should really be done on a branch in the main repo[1]. This setup seems overly complicated and confusing (though I recognize you are just working with limitations imposed upon you). I'd like to propose an alternative to this cherry-picking solution though which is much easier and plays to git's strengths. 1. Features would be pull requests targeting D-P-L/dmd:master. Walter could still push his features directly. 2. Bugfixes would be pull requests targeting D-P-L/dmd:stable. Walter could still push his bugfixes directly. 3. D-P-L/dmd:master would periodically merge D-P-L/dmd:stable to pull bug fixes in. This setup requires almost no changes by all contributors. Here is a mini guide for contributors outlining the slightly changed workflow. Working on a bugfix: 1. git checkout -b issue-555 stable 2. ... hack hack hack commit ... 3. git push origin issue-555 (Walter can just do `git push origin stable` and skip step 4, assuming origin is D-P-L) 4. Make pull request targeting stable (most people already do this but branch from ma
Re: Coming Soon: Stable D Releases!
On Monday, July 16, 2012 13:18:55 Caligo wrote: > What?! > > All he has to do is create a branch and call it stable, or whatever, > and use cherry-pick to move small stables patches from other branches > to the stable branch. What's so difficult about that? I don't get > it. It takes up his time for him to do it, and I don't think that there's any chance whatsoever of him giving someone else commit access to the main dmd repository to do this (certainly not at this point). He wasn't interested in changing the versioning or branching stuff at all. He agreed to this plan (which should be minimally disruptive to him) as an experiment. Depending on how it goes, we may change how we deal with the main repo, but for now, we're trying this. And since the likely alternative was that we would continue on exactly as we have been, this is presumably an improvement for the folks who wanted a branch with bug fixes with more frequent releases. - Jonathan M Davis
Re: Coming Soon: Stable D Releases!
On Mon, 16 Jul 2012 10:39:04 -0700, Iain Buclaw wrote: On 16 July 2012 18:31, Adam Wilson wrote: On Mon, 16 Jul 2012 09:21:39 -0700, Iain Buclaw wrote: On 16 July 2012 14:00, Marco Leise wrote: Am Mon, 16 Jul 2012 00:51:16 -0700 schrieb "Adam Wilson" : As it shows, the beta phase doesn't always catch all regressions in people's code, so I encourage you to do this project and eventually it will be used by GDC and other major from-source projects. By the way: Should this also later become the base for the official zip file download? IIRC Walter wanted to keep track of the DMD downloads from the main web site (no redistribution) and hotfixed versions of D could become increasingly popular. -- Marco And what benefits would GDC get from opting to use this rather than the normal releases? The main benefit I could see is the faster cycle focusing on bugs. I don't know what GCC's release cycle is (something tells me it's pretty glacial), but for any users of your Git-HEAD code, the bug fixes could certainly appear faster. It's roughly once a year, maybe a little less. Depends on regressions, open bugs, etc. In other words, glacial. :-) But, if it's of interest to you to use the stable releases as a basis for GDC we wouldn't mind. -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Re: Coming Soon: Stable D Releases!
On 16 July 2012 19:48, Adam Wilson wrote: > On Mon, 16 Jul 2012 10:39:04 -0700, Iain Buclaw wrote: > >> On 16 July 2012 18:31, Adam Wilson wrote: >>> >>> On Mon, 16 Jul 2012 09:21:39 -0700, Iain Buclaw >>> wrote: >>> On 16 July 2012 14:00, Marco Leise wrote: > > > Am Mon, 16 Jul 2012 00:51:16 -0700 > schrieb "Adam Wilson" : > > As it shows, the beta phase doesn't always catch all regressions in > people's code, so I encourage you to do this project and eventually it > will > be used by GDC and other major from-source projects. By the way: Should > this > also later become the base for the official zip file download? IIRC > Walter > wanted to keep track of the DMD downloads from the main web site (no > redistribution) and hotfixed versions of D could become increasingly > popular. > > -- > Marco > And what benefits would GDC get from opting to use this rather than the normal releases? >>> >>> The main benefit I could see is the faster cycle focusing on bugs. I >>> don't >>> know what GCC's release cycle is (something tells me it's pretty >>> glacial), >>> but for any users of your Git-HEAD code, the bug fixes could certainly >>> appear faster. >>> >> >> It's roughly once a year, maybe a little less. Depends on >> regressions, open bugs, etc. >> > > In other words, glacial. :-) But, if it's of interest to you to use the > stable releases as a basis for GDC we wouldn't mind. > > Will see how it goes. Typically in the past I have cherry picked creamy features (__vector support, the recent updates to align) and merged in any fixes for bugs raised in GDC that are because of, and fixed in the D frontend prior to merging releases. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Re: Coming Soon: Stable D Releases!
On 7/16/12 2:14 PM, Brad Anderson wrote: [snip] What is gained by this is that nobody needs to cherry-pick bugfixes into a stable repo. Cherry-picking is a substantial amount of work (for which I salute you for volunteering to undertake). It just seems unnecessary in the world of git. I'd like to stress one more time that **this is basically no additional work for contributors or Walter**. It's simply categorizing changes. The setup you are planning will work, of course, but I do not envy the amount of labor it will require. Whichever way it is done is a step in the right direction and I'm glad you are taking it on. Regards, Brad Anderson I agree this would be more direct. But I fail to see how Walter cherry-picking stuff is "basically no additional work", whereas Adam doing essentially the same is an unenviable "amount of labor". Besides, if Walter is at the same time doing things and deciding their category may work worse than a small team making the assessment by consensus. Andrei
Re: Coming Soon: Stable D Releases!
On Mon, 16 Jul 2012 09:41:30 -0700, Andrei Alexandrescu wrote: On 7/16/12 3:51 AM, Adam Wilson wrote: As a result of the D Versioning thread, we have decided to create a new organization on Github called dlang-stable. This organization will be responsible for maintaining stable releases of DMD, DRuntime, and Phobos. [snip] Thank you for reading and I hope you enjoy D's new Stable releases! This is a wonderful initiative that I hope will catch on. Walter and I are fully behind this experiment. We will make/accept changes to the download pages to take into account this new branch. The main threat I see is bugfixes that depend on code previously introduced with now features. I'm not sure how frequent that situation is. Finally, one suggestion: I suggest you relentlessly work to automate the process to the point where you issue e.g. the command ./merge 534d44c979 70dcb958ea and the script merges in the two specified commits, builds everything, runs the test suite, runs the Phobos unittests, and if all worked, builds packages and uploads them making them available right away. The only problem I can see with this is that the build would only for whichever OS the merger happens to be running on. A two step process is about the best we can do. ./merge does the following git fetch upstream git cherry-pick 534d44c979 git cherry-pick 70dcb958ea If the cherry pick is successful, push to master, which will need to be done manually in case any merge conflicts arise. ./build does the following for all projects git fetch origin git merge origin/master make clean -f .mak make -f .mak make unittests -f .mak As for actually putting together the script, my Bash-fu, is not as strong as my PowerShell-fu, but with some effort it could be achieved. Both are not terribly difficult (expect for the uploading part). That way the team members (busy professionals with many other responsibilities) know that once the collective decision to merge a commit has been taken, there's virtually no overhead to deploying the decision. I'm a huge fan of automation and I believe we've made progress introducing it in dmd's process, but not as much as we could and should. Good luck! Andrei -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Re: Coming Soon: Stable D Releases!
On Monday, 16 July 2012 at 19:35:47 UTC, Andrei Alexandrescu wrote: [snip] I agree this would be more direct. But I fail to see how Walter cherry-picking stuff is "basically no additional work", whereas Adam doing essentially the same is an unenviable "amount of labor". He wouldn't be cherry-picking anything. All he'd have to do is a checkout (one command) before switching between working on features (and by features I mean breaking or major changes) or bugs. Adam, on the other hand, would be running git cherry-pick over and over dodging changes he determines are too risky to include in stable. It also seems like there is a lot more room for mistakes to be made doing it this way. Besides, if Walter is at the same time doing things and deciding their category may work worse than a small team making the assessment by consensus. Perhaps. More eyes are better. It just seems like way more work than is necessary to accomplish the goal of isolating breaking changes so that stable releases can go out easier. The end result is all I'm interested in personally since I'm not the one doing the work here. I'm not too concerned with whether you use my idea or not. I just thought you guys might like to hear an alternative that is much easier for you while remaining easy for Walter. Regards, Brad Anderson
Re: Coming Soon: Stable D Releases!
On 2012-07-16 21:37, Adam Wilson wrote: The only problem I can see with this is that the build would only for whichever OS the merger happens to be running on. A two step process is about the best we can do. ./merge does the following git fetch upstream git cherry-pick 534d44c979 git cherry-pick 70dcb958ea If the cherry pick is successful, push to master, which will need to be done manually in case any merge conflicts arise. How would this work? Isn't the whole point of cherry picking to be able to choose what to pick from a branch and not picking everything? ./build does the following for all projects git fetch origin git merge origin/master make clean -f .mak make -f .mak make unittests -f .mak As for actually putting together the script, my Bash-fu, is not as strong as my PowerShell-fu, but with some effort it could be achieved. Both are not terribly difficult (expect for the uploading part). You could use DVM with the "compile" command to build everything. https://bitbucket.org/doob/dvm -- /Jacob Carlborg
Re: Coming Soon: Stable D Releases!
On Mon, 16 Jul 2012 23:17:38 -0700, Jacob Carlborg wrote: On 2012-07-16 21:37, Adam Wilson wrote: The only problem I can see with this is that the build would only for whichever OS the merger happens to be running on. A two step process is about the best we can do. ./merge does the following git fetch upstream git cherry-pick 534d44c979 git cherry-pick 70dcb958ea If the cherry pick is successful, push to master, which will need to be done manually in case any merge conflicts arise. How would this work? Isn't the whole point of cherry picking to be able to choose what to pick from a branch and not picking everything? Each parameter represents a specific commit ID to pick. ./build does the following for all projects git fetch origin git merge origin/master make clean -f .mak make -f .mak make unittests -f .mak As for actually putting together the script, my Bash-fu, is not as strong as my PowerShell-fu, but with some effort it could be achieved. Both are not terribly difficult (expect for the uploading part). You could use DVM with the "compile" command to build everything. https://bitbucket.org/doob/dvm Hmm, this sounds like an interesting method, can it be targeted at any repo and if so how? And does it run unittests? -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Re: Coming Soon: Stable D Releases!
On Mon, 16 Jul 2012 23:24:04 -0700 "Adam Wilson" wrote: > On Mon, 16 Jul 2012 23:17:38 -0700, Jacob Carlborg > wrote: > > > On 2012-07-16 21:37, Adam Wilson wrote: > > > >> ./build does the following for all projects > >> git fetch origin > >> git merge origin/master > >> make clean -f .mak > >> make -f .mak > >> make unittests -f .mak > >> > >> As for actually putting together the script, my Bash-fu, is not as > >> strong as my PowerShell-fu, but with some effort it could be > >> achieved. Both are not terribly difficult (expect for the > >> uploading part). > > > > You could use DVM with the "compile" command to build everything. > > > > https://bitbucket.org/doob/dvm > > Hmm, this sounds like an interesting method, can it be targeted at > any repo and if so how? And does it run unittests? > dvm compile Where is a directory that contains git clones of dmd, phobos, druntime, and optionally DMD's tools repo. So whatever branch/version is checked out in that directory, that's what dvm will compile. It's not very flexible though. For example, it doesn't support passing arbitrary flags/params to make. RDMD is the only program from the tools repo it tries to compile. IIRC, it always does a clean build (or at least to the extent that the "clean" in DMD's makefiles actually works in the first place - ie, not always perfectly). It doesn't run unittests, IIRC. And I think there's a thing or two (I forget what) that it does slightly different between windows and posix (this was due to the targets and features available/unavailable in the makefiles being completely fucking different between windows and posix). Also, if you're compiling Git sources (instead of recompiling a DMD release), then it doesn't attempt to recreate the DMD release directory structure, instead it just puts the bins in /dmd/bin(32|64)/ (or something like that, don't recall exactly) and sets up sc.ini/dmd.conf to use the phobos in /phobos, etc. And then there's a little magic to be aware of: For some stuff (like windows libs) we don't have source on Github, so it automagically pulls those in from whatever it detects is the latest official release (downloading it if necessary). (tl;dr): Main thing to remember is, as it's written right now, it was really intended more for people building DMD/Druntime/Phobos themself and then just using it. Not much thought went into using it to create packaged releases. So if happens to do what you need it to, then fantastic, but you should probably try it out first (with the --verbose flag) and pay close attention to what it's doing. Then see if that matches what you need. If so, great! If not, then file a ticket, and with luck maybe Jacob or I may be able to find some time to take care of it. But I've been busy though, so I can't promise anything :( Or just deal with bash ;) Either way.
Re: Coming Soon: Stable D Releases!
On 2012-07-17 08:24, Adam Wilson wrote: Each parameter represents a specific commit ID to pick. So you would pass those to the script? -- /Jacob Carlborg
Re: Coming Soon: Stable D Releases!
On Tue, 17 Jul 2012 02:08:55 -0700, Jacob Carlborg wrote: On 2012-07-17 08:24, Adam Wilson wrote: Each parameter represents a specific commit ID to pick. So you would pass those to the script? Yup, I think that's probably the safest way to do it. Given the goals of the project, we need to be explicit about which commits we choose so forcing the maintainers to write down every commit is good practice. -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Re: Coming Soon: Stable D Releases!
On 2012-07-17 19:04, Adam Wilson wrote: Yup, I think that's probably the safest way to do it. Given the goals of the project, we need to be explicit about which commits we choose so forcing the maintainers to write down every commit is good practice. Exactly. I took that example a bit too literal, that's what confused me. -- /Jacob Carlborg
Re: Coming Soon: Stable D Releases!
On Monday, 16 July 2012 at 19:35:47 UTC, Andrei Alexandrescu wrote: I agree this would be more direct. But I fail to see how Walter cherry-picking stuff is "basically no additional work", whereas Adam doing essentially the same is an unenviable "amount of labor". Well, if things go well, there is a system that could make things much simpler. But my thought would that Walter wouldn't need to touch the stable branch. The only benefit for the new org is a separate set of contributes and separate pull requests. If this system takes off, while still having a cost to Walter, there would be a stable branch which get all the bug fixes and the new feature branch. When adding a bug fix just merge the stable branch into the feature branch. This won't always be a clean merge. Good luck Adam.
Re: Coming Soon: Stable D Releases!
Just curious, if Walter is too busy to make DMD more stable, then what does he spend most of his time on? I thought we were done with adding new features to the language (at least for now)? On Mon, Jul 16, 2012 at 1:29 PM, Jonathan M Davis wrote: > On Monday, July 16, 2012 13:18:55 Caligo wrote: >> What?! >> >> All he has to do is create a branch and call it stable, or whatever, >> and use cherry-pick to move small stables patches from other branches >> to the stable branch. What's so difficult about that? I don't get >> it. > > It takes up his time for him to do it, and I don't think that there's any > chance whatsoever of him giving someone else commit access to the main dmd > repository to do this (certainly not at this point). He wasn't interested in > changing the versioning or branching stuff at all. He agreed to this plan > (which should be minimally disruptive to him) as an experiment. Depending on > how it goes, we may change how we deal with the main repo, but for now, we're > trying this. And since the likely alternative was that we would continue on > exactly as we have been, this is presumably an improvement for the folks who > wanted a branch with bug fixes with more frequent releases. > > - Jonathan M Davis
Re: Coming Soon: Stable D Releases!
On Wed, 18 Jul 2012 22:20:51 -0700, Caligo wrote: Just curious, if Walter is too busy to make DMD more stable, then what does he spend most of his time on? I thought we were done with adding new features to the language (at least for now)? While COFF/x64 support for is technically a new feature, it's also one required for the survival of D. x86 is dead on OS X, and dying on Windows and Linux. So i'd say that it's pretty important for Walter to get it in now. On Mon, Jul 16, 2012 at 1:29 PM, Jonathan M Davis wrote: On Monday, July 16, 2012 13:18:55 Caligo wrote: What?! All he has to do is create a branch and call it stable, or whatever, and use cherry-pick to move small stables patches from other branches to the stable branch. What's so difficult about that? I don't get it. It takes up his time for him to do it, and I don't think that there's any chance whatsoever of him giving someone else commit access to the main dmd repository to do this (certainly not at this point). He wasn't interested in changing the versioning or branching stuff at all. He agreed to this plan (which should be minimally disruptive to him) as an experiment. Depending on how it goes, we may change how we deal with the main repo, but for now, we're trying this. And since the likely alternative was that we would continue on exactly as we have been, this is presumably an improvement for the folks who wanted a branch with bug fixes with more frequent releases. - Jonathan M Davis -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Re: Coming Soon: Stable D Releases!
On Thursday, July 19, 2012 00:20:51 Caligo wrote: > Just curious, if Walter is too busy to make DMD more stable, then what > does he spend most of his time on? I thought we were done with adding > new features to the language (at least for now)? No one said anything about Walter not making dmd more stable. What he doesn't have time to spend on is managing a separate branch which includes only bug fixes. He spends lots of time on both bug fixing and new stuff, and his skills are valuable enough that his time is better spent on actually coding than dealing with branch management. Currently, he's focusing on adding COFF support for Windows, which will make it possible to link using Microsoft's linker and generate 64-bit binaries. It's not a new feature in the sense that the language itself is gaining a feature, but it _is_ new functionality for the compiler. - Jonathan M Davis
Re: Coming Soon: Stable D Releases!
Adam Wilson, el 16 de July a las 11:01 me escribiste: > On Mon, 16 Jul 2012 01:56:23 -0700, Leandro Lucarella > wrote: > > >Adam Wilson, el 16 de July a las 00:51 me escribiste: > >>As a result of the D Versioning thread, we have decided to create a > >>new organization on Github called dlang-stable. This organization > >>will be responsible for maintaining stable releases of DMD, > >>DRuntime, and Phobos. > > > >What will be the version scheme of this dlang-stable compiler? If the > >git master branch will be the "release", will you increase that version > >number on each and every commit? > > We will probably only bump the version number for packaged releases. > Anything else is going to be a lot of relatively useless > wheel-spinning. What I would suggest is if you fork from 1.060, to release 1.060.1, 1.060.2, etc. So is easy to find out what set of features are present in a stable release every time. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Robar un alfajor es revolucionario, pues rompe con la idea de propiedad, incluso más que si se tratara de dinero. -- publikazion anarkista mdp (hablando de los destrozos de la Cumbre de las Americas en Mar del Plata, 2005)
Re: Coming Soon: Stable D Releases!
Adam Wilson, el 16 de July a las 10:56 me escribiste: > >So if I were to represent a theoretical merge sequence in ascii: > > > >... former releases ... > >DMD Development GDC Development > > > DMD 2.060 release > > > | | > > DMD Development DMD 2.060.1 release > > v v > > | | > > | DMD 2.060.2 release > > | v > > | | > > | DMD 2.060.3 release > > | v > > | | > > DMD 2.061 beta DMD 2.060.4 release > > v v > > | | > > DMD 2.061 RCDMD 2.060.5 release > > v v > > | | > > >-- DMD 2.061 release --> > > > > > >Would this be a correct way of utilising this new process? > > > > I'd say mostly correct. The last step is the one where we might Mmm, this makes me wonder if the stable releases based on a particular official release will live only until the next official release is out, or if they will be long-term. I thought it was the later, so people don't have to worry about bugs related to new features they don't care about, but now I'm not so sure. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- ACCIDENTE FATAL EN FLORES, MUEREN DOS PERSONAS Y UN BOLIVIANO -- Crónica TV
Re: Coming Soon: Stable D Releases!
Andrei Alexandrescu, el 16 de July a las 12:41 me escribiste: > On 7/16/12 3:51 AM, Adam Wilson wrote: > >As a result of the D Versioning thread, we have decided to create a new > >organization on Github called dlang-stable. This organization will be > >responsible for maintaining stable releases of DMD, DRuntime, and Phobos. > [snip] > >Thank you for reading and I hope you enjoy D's new Stable releases! > > This is a wonderful initiative that I hope will catch on. > > Walter and I are fully behind this experiment. We will make/accept > changes to the download pages to take into account this new branch. > > The main threat I see is bugfixes that depend on code previously > introduced with now features. I'm not sure how frequent that > situation is. > > Finally, one suggestion: I suggest you relentlessly work to automate > the process to the point where you issue e.g. the command > > ./merge 534d44c979 70dcb958ea > > and the script merges in the two specified commits, builds > everything, runs the test suite, runs the Phobos unittests, and if > all worked, builds packages and uploads them making them available > right away. If he is just going to cherry pick patches, then that can be all automated using git directly, using a commit hook to test the commit (and reject it if it fails). Something that everybody should have if running the test suite weren't so slow :P What you can do is have a git repository in the test suite server, and plug git to the autotester, and make it only succeed if the autotester result was good, the resulting repository will NEVER have a non-working DMD. This way the testing is asynchronous, so it doesn't bother the developer, but you also make sure the "good" public repository is always healthy, something that is not happening now because is the other way around. Walter first pushes changes to the "good" public repository and the autotester runs after the commits are published, so there is no way to undo the commits and fix them privately. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- "The Guinness Book of Records" holds the record for being the most stolen book in public libraries
Re: Coming Soon: Stable D Releases!
On Sat, 21 Jul 2012 07:32:19 -0700, Leandro Lucarella wrote: Adam Wilson, el 16 de July a las 10:56 me escribiste: >So if I were to represent a theoretical merge sequence in ascii: > >... former releases ... >DMD Development GDC Development > > DMD 2.060 release > > | | > DMD Development DMD 2.060.1 release > v v > | | > | DMD 2.060.2 release > | v > | | > | DMD 2.060.3 release > | v > | | > DMD 2.061 beta DMD 2.060.4 release > v v > | | > DMD 2.061 RCDMD 2.060.5 release > v v > | | > >-- DMD 2.061 release --> > > >Would this be a correct way of utilising this new process? > I'd say mostly correct. The last step is the one where we might Mmm, this makes me wonder if the stable releases based on a particular official release will live only until the next official release is out, or if they will be long-term. I thought it was the later, so people don't have to worry about bugs related to new features they don't care about, but now I'm not so sure. Actually, I specifically mention that new features will left out until stability is achieved. But at some point we will fold in the new features from HEAD, our goal is to specifically AVOID creating a D1/D2 style split. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- ACCIDENTE FATAL EN FLORES, MUEREN DOS PERSONAS Y UN BOLIVIANO -- Crónica TV -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Re: Coming Soon: Stable D Releases!
On Sat, 21 Jul 2012 07:27:39 -0700, Leandro Lucarella wrote: Adam Wilson, el 16 de July a las 11:01 me escribiste: On Mon, 16 Jul 2012 01:56:23 -0700, Leandro Lucarella wrote: >Adam Wilson, el 16 de July a las 00:51 me escribiste: >>As a result of the D Versioning thread, we have decided to create a >>new organization on Github called dlang-stable. This organization >>will be responsible for maintaining stable releases of DMD, >>DRuntime, and Phobos. > >What will be the version scheme of this dlang-stable compiler? If the >git master branch will be the "release", will you increase that version >number on each and every commit? We will probably only bump the version number for packaged releases. Anything else is going to be a lot of relatively useless wheel-spinning. What I would suggest is if you fork from 1.060, to release 1.060.1, 1.060.2, etc. So is easy to find out what set of features are present in a stable release every time. This seems to be the general consensus and I think it's where we'll go. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Robar un alfajor es revolucionario, pues rompe con la idea de propiedad, incluso más que si se tratara de dinero. -- publikazion anarkista mdp (hablando de los destrozos de la Cumbre de las Americas en Mar del Plata, 2005) -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Re: Coming Soon: Stable D Releases!
Adam Wilson, el 21 de July a las 15:03 me escribiste: > >Mmm, this makes me wonder if the stable releases based on a particular > >official release will live only until the next official release is out, > >or if they will be long-term. I thought it was the later, so people > >don't have to worry about bugs related to new features they don't care > >about, but now I'm not so sure. > > Actually, I specifically mention that new features will left out > until stability is achieved. But at some point we will fold in the > new features from HEAD, our goal is to specifically AVOID creating a > D1/D2 style split. Yes, of course, but these updates will not be done for each and every official DMD release, they will be done in a timespan in the order of years for example? I.e. like any other serious language out there? :P -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- The biggest lie you can tell yourself is When I get what I want I will be happy
Re: Coming Soon: Stable D Releases!
On Sun, 22 Jul 2012 11:59:39 -0700, Leandro Lucarella wrote: Adam Wilson, el 21 de July a las 15:03 me escribiste: >Mmm, this makes me wonder if the stable releases based on a particular >official release will live only until the next official release is out, >or if they will be long-term. I thought it was the later, so people >don't have to worry about bugs related to new features they don't care >about, but now I'm not so sure. Actually, I specifically mention that new features will left out until stability is achieved. But at some point we will fold in the new features from HEAD, our goal is to specifically AVOID creating a D1/D2 style split. Yes, of course, but these updates will not be done for each and every official DMD release, they will be done in a timespan in the order of years for example? I.e. like any other serious language out there? :P -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- The biggest lie you can tell yourself is When I get what I want I will be happy I can't really say, but it sounds like what you are asking for is D2/D3, thats not really the scope of the dlang-stable project, we just want builds of D2 that do not include new features until the community feels that those features are stable enough. Which means we will periodically roll in the new features, probably on the order of months, which pretty typical for 2.x type releases. If Walter does eventually decide on a D3, then we will probably maintain a separate D2 maintenance branch for a while, like all the other big compilers, but that's years on down the road. -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Re: Coming Soon: Stable D Releases!
On Mon, 16 Jul 2012 13:05:29 -0700, Brad Anderson wrote: On Monday, 16 July 2012 at 19:35:47 UTC, Andrei Alexandrescu wrote: [snip] I agree this would be more direct. But I fail to see how Walter cherry-picking stuff is "basically no additional work", whereas Adam doing essentially the same is an unenviable "amount of labor". He wouldn't be cherry-picking anything. All he'd have to do is a checkout (one command) before switching between working on features (and by features I mean breaking or major changes) or bugs. Adam, on the other hand, would be running git cherry-pick over and over dodging changes he determines are too risky to include in stable. It also seems like there is a lot more room for mistakes to be made doing it this way. There certainly is more room for mistakes, which is why I think that a team-based approach is better. I've also finished putting together some scripts to automate the various processes. I think that the merge script can especially take a lot of the work and time out of the equation. With a single call we can merge as many commits as we feel comfortable with, build them, run unittests and push the changes to the server. At this point i'll probably spend more time deciding which commits are safe to pick than I will actually merging them. At least until I hit a decent merge conflict. But hey, everything helps! :-) Scripts are available here: https://github.com/dlang-stable/utilities Besides, if Walter is at the same time doing things and deciding their category may work worse than a small team making the assessment by consensus. Perhaps. More eyes are better. It just seems like way more work than is necessary to accomplish the goal of isolating breaking changes so that stable releases can go out easier. The end result is all I'm interested in personally since I'm not the one doing the work here. I'm not too concerned with whether you use my idea or not. I just thought you guys might like to hear an alternative that is much easier for you while remaining easy for Walter. Regards, Brad Anderson -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Re: Coming Soon: Stable D Releases!
Adam Wilson, el 22 de July a las 16:05 me escribiste: > I can't really say, but it sounds like what you are asking for is > D2/D3, thats not really the scope of the dlang-stable project, we Nope! What I'm talking about is D 2.1, 2.2, etc. Not D3. As somebody said before in this thread talking about PHP, minor version changes in the languages should only introduce backward compatible new features. D3 should be allowed to break backward compatibility while D 2.1 should not. The same is done in Python. In Python is even allowed to break backward compatibility in very small and are cases, like introducing a keyword. In those cases the changes are introduced in steps, let's say in Python 2.5 with is not a keyword and they want to convert it to a keyword. Then in Python 2.6 you have an option to enable that behaviour (disabled by default) and in Python 2.7 the new feature will be enabled by default. Python 2.5.1 can only introduce bugfixes. This is something I think D needs since ages ago[1], and I thought it was finally here, but from what you say it doesn't like that way :S [1] http://www.llucax.com.ar/blog/blog/post/6cac01e1#source-control-and-versioning -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- There is no pain you are receding A distant ship, smoke on the horizon. You are only coming through in waves. Your lips move but I can't hear what you're saying.
Re: Coming Soon: Stable D Releases!
On Mon, 23 Jul 2012 01:52:57 -0700, Leandro Lucarella wrote: Adam Wilson, el 22 de July a las 16:05 me escribiste: I can't really say, but it sounds like what you are asking for is D2/D3, thats not really the scope of the dlang-stable project, we Nope! What I'm talking about is D 2.1, 2.2, etc. Not D3. As somebody said before in this thread talking about PHP, minor version changes in the languages should only introduce backward compatible new features. D3 should be allowed to break backward compatibility while D 2.1 should not. The same is done in Python. In Python is even allowed to break backward compatibility in very small and are cases, like introducing a keyword. In those cases the changes are introduced in steps, let's say in Python 2.5 with is not a keyword and they want to convert it to a keyword. Then in Python 2.6 you have an option to enable that behaviour (disabled by default) and in Python 2.7 the new feature will be enabled by default. Python 2.5.1 can only introduce bugfixes. Minor release ARE what we are hoping for, but you'll have to convince Walter and company to move to that scheme, it's out of my control. For the moment, we will be using a scheme that looks like 2.60.1. Which may be what you are talking about. When it's time to roll in the new features and breaking fixes the stable release will be bumped to 2.61.1. Is this what you are asking for? This is something I think D needs since ages ago[1], and I thought it was finally here, but from what you say it doesn't like that way :S [1] http://www.llucax.com.ar/blog/blog/post/6cac01e1#source-control-and-versioning -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- There is no pain you are receding A distant ship, smoke on the horizon. You are only coming through in waves. Your lips move but I can't hear what you're saying. -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Re: Coming Soon: Stable D Releases!
On 16/07/12 09:51, Adam Wilson wrote: As a result of the D Versioning thread, we have decided to create a new organization on Github called dlang-stable. This organization will be responsible for maintaining stable releases of DMD, DRuntime, and Phobos. So what is a stable release? A stable release is a complete build of DMD, DRuntime, and Phobos that ONLY includes the latest bug-fixes and non-breaking enhancements to existing features. It will not include, new features, breaking enhancements, and any other code that the core development team may be working on. I'm not actually sure what this means. I fear that it may be motivated by an inaccurate assessment of the current situation. The existing instability comes almost entirely from Phobos, not from the compiler. Historically there have been very few instances where you might want to choose an older compiler in preference to the latest release. As I've said before, the one time when a language change caused *massive* instability was in the attempt to move AAs from language to library -- even though that wasn't even supposed to affect existing code in any way. The other thing that typically causes regressions is fixes to forward-reference bugs. Historically, addition of new language features has NOT caused instability. What has been true is that features have been added to the compiler before they were really usable, but they have not broken existing code. Fairly obviously the 64 bit compiler was quite buggy when initially released. But even that massive change wasn't much more buggy than the library AAs! So I am not sure that you can correctly guess where instability will come from. In summary -- I would not expect your stable DMD to be very different from the normal DMD. Phobos is where the instability issue is.
Re: Coming Soon: Stable D Releases!
On Monday, 16 July 2012 at 19:35:47 UTC, Andrei Alexandrescu wrote: I agree this would be more direct. But I fail to see how Walter cherry-picking stuff is "basically no additional work", whereas Adam doing essentially the same is an unenviable "amount of labor". The difference is Walter (and other developers) knows his changes intimately. The whole point of dlang-stable is to deliver bug-fixes more quickly. To make this work developers should fix bugs in separate branch, and do separate commit (IIUC, which I'm not quite sure). So it's virtually zero effort on their side. On the other hand, Adam must look at this code really closely. Now add to the picture other developers whom changes Adam will need to examine too. All of his D-love energy will be consumed by maybe 5 developers. And I don't understand what benefits are (given zero effort for developers). This doesn't scale. At some point number of the compiler developers will be 100 times then it is now. And that will require 100 times more Adams to handle the stream. Besides, if Walter is at the same time doing things and deciding their category may work worse than a small team making the assessment by consensus. That (few people reviewing same patches) would scale even worse. B.t.w. how does Linux kernel people handle this ?
Re: Coming Soon: Stable D Releases!
On Tue, 24 Jul 2012 01:50:02 -0700, Don Clugston wrote: On 16/07/12 09:51, Adam Wilson wrote: As a result of the D Versioning thread, we have decided to create a new organization on Github called dlang-stable. This organization will be responsible for maintaining stable releases of DMD, DRuntime, and Phobos. So what is a stable release? A stable release is a complete build of DMD, DRuntime, and Phobos that ONLY includes the latest bug-fixes and non-breaking enhancements to existing features. It will not include, new features, breaking enhancements, and any other code that the core development team may be working on. I'm not actually sure what this means. I fear that it may be motivated by an inaccurate assessment of the current situation. The existing instability comes almost entirely from Phobos, not from the compiler. Historically there have been very few instances where you might want to choose an older compiler in preference to the latest release. As I've said before, the one time when a language change caused *massive* instability was in the attempt to move AAs from language to library -- even though that wasn't even supposed to affect existing code in any way. The other thing that typically causes regressions is fixes to forward-reference bugs. Historically, addition of new language features has NOT caused instability. What has been true is that features have been added to the compiler before they were really usable, but they have not broken existing code. Fairly obviously the 64 bit compiler was quite buggy when initially released. But even that massive change wasn't much more buggy than the library AAs! So I am not sure that you can correctly guess where instability will come from. In summary -- I would not expect your stable DMD to be very different from the normal DMD. Phobos is where the instability issue is. There are three issues we are trying to address: The first and largest issue is the long and variable periods between DMD releases. By the end of the 2.060 Beta period there will have been at least 3.5 months since 2.059. And while for the people who can use Git HEAD this may not be a problem, there are MANY who, for whatever reason, must use the released versions. For them the 314 resolved issues and dozens of regressions fixed are a tantalizingly out of reach. The second issue is the root of the first. Much of the delay was caused by Walter starting to work on COFF. Which brings up the second point of contention in the community, a significant number of bugs are typically introduced when this new work is introduced precisely because it's not ready, and the effort required to make it stable would significantly delay the release, which loops back to the first problem of release cadence. Yes, D is more stable than ever, but we keep breaking it to push bugfix builds because the community starts to get restless without bugfixes. Which is the whole reason this stable project got started. The third is the result of the first two. The slow release cadence combined with the requirement to push new features along side bug-fixes is seriously holding back the growth of the D community. There is a feeling out here that D is lurching unsteadily forward when it should be smoothly accelerating and most of this feeling is rooted in the prior two causes. This has a very corrosive effect on the community and particularly their willingness to contribute. The goal of dlang-stable is to provide the primary development team (you!) with the ability to release whenever you feel a new feature or enhancement is stable enough to be released WITHOUT having to worry about the ever growing number of bugfixes that are backlogged in with the new features. We are trying to reduce the bugfix pressure so that you can focus on delivering high-quality code when it's ready. The community WANTS these new features, but we CAN'T wait 3.5 months (or more!) for the bugfixes that are baked in with them. We have to provide BOTH. That is dlang-stable. -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Re: Coming Soon: Stable D Releases!
Adam Wilson, el 23 de July a las 11:07 me escribiste: > On Mon, 23 Jul 2012 01:52:57 -0700, Leandro Lucarella > wrote: > > >Adam Wilson, el 22 de July a las 16:05 me escribiste: > >>I can't really say, but it sounds like what you are asking for is > >>D2/D3, thats not really the scope of the dlang-stable project, we > > > >Nope! What I'm talking about is D 2.1, 2.2, etc. Not D3. As somebody > >said before in this thread talking about PHP, minor version changes in > >the languages should only introduce backward compatible new features. D3 > >should be allowed to break backward compatibility while D 2.1 should > >not. The same is done in Python. In Python is even allowed to break > >backward compatibility in very small and are cases, like introducing > >a keyword. In those cases the changes are introduced in steps, let's say > >in Python 2.5 with is not a keyword and they want to convert it to > >a keyword. Then in Python 2.6 you have an option to enable that > >behaviour (disabled by default) and in Python 2.7 the new feature will > >be enabled by default. Python 2.5.1 can only introduce bugfixes. > > Minor release ARE what we are hoping for, but you'll have to > convince Walter and company to move to that scheme, it's out of my Are you talking about the development model or just the version naming scheme? > control. For the moment, we will be using a scheme that looks like > 2.60.1. Which may be what you are talking about. When it's time to > roll in the new features and breaking fixes the stable release will > be bumped to 2.61.1. Is this what you are asking for? I guess. But if after 2.60.1, when you want to make a new "minor" release with new features, you fork it from, say, 2.064, I would name that new version, 2.64.1 instead of 2.61.1. Or with that comment you are implying that there will be "minor" release for each and every official release? Also, are you planning to drop the leading 0 in the version number or was just a typo? -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Que barbaridad, este país se va cada ves más pa' tras, más pa' tras... -- Sidharta Kiwi
Re: Coming Soon: Stable D Releases!
On Tue, 24 Jul 2012 11:41:52 -0700, Leandro Lucarella wrote: Adam Wilson, el 23 de July a las 11:07 me escribiste: On Mon, 23 Jul 2012 01:52:57 -0700, Leandro Lucarella wrote: >Adam Wilson, el 22 de July a las 16:05 me escribiste: >>I can't really say, but it sounds like what you are asking for is >>D2/D3, thats not really the scope of the dlang-stable project, we > >Nope! What I'm talking about is D 2.1, 2.2, etc. Not D3. As somebody >said before in this thread talking about PHP, minor version changes in >the languages should only introduce backward compatible new features. D3 >should be allowed to break backward compatibility while D 2.1 should >not. The same is done in Python. In Python is even allowed to break >backward compatibility in very small and are cases, like introducing >a keyword. In those cases the changes are introduced in steps, let's say >in Python 2.5 with is not a keyword and they want to convert it to >a keyword. Then in Python 2.6 you have an option to enable that >behaviour (disabled by default) and in Python 2.7 the new feature will >be enabled by default. Python 2.5.1 can only introduce bugfixes. Minor release ARE what we are hoping for, but you'll have to convince Walter and company to move to that scheme, it's out of my Are you talking about the development model or just the version naming scheme? control. For the moment, we will be using a scheme that looks like 2.60.1. Which may be what you are talking about. When it's time to roll in the new features and breaking fixes the stable release will be bumped to 2.61.1. Is this what you are asking for? I guess. But if after 2.60.1, when you want to make a new "minor" release with new features, you fork it from, say, 2.064, I would name that new version, 2.64.1 instead of 2.61.1. Or with that comment you are implying that there will be "minor" release for each and every official release? Also, are you planning to drop the leading 0 in the version number or was just a typo? Yes, the minor will match the minor it's forked from, that is important to semantically understanding which release the bugfixes apply to. There will many releases per minor. So 2.060.1, 2.060.2, etc. I am hoping for packaged releases every week. I would like to drop the leading 0, but I think it would be confusing to people to not have them exactly match D's current scheme. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Que barbaridad, este país se va cada ves más pa' tras, más pa' tras... -- Sidharta Kiwi -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Re: Coming Soon: Stable D Releases!
On 24/07/12 19:27, Adam Wilson wrote: On Tue, 24 Jul 2012 01:50:02 -0700, Don Clugston wrote: On 16/07/12 09:51, Adam Wilson wrote: As a result of the D Versioning thread, we have decided to create a new organization on Github called dlang-stable. This organization will be responsible for maintaining stable releases of DMD, DRuntime, and Phobos. So what is a stable release? A stable release is a complete build of DMD, DRuntime, and Phobos that ONLY includes the latest bug-fixes and non-breaking enhancements to existing features. It will not include, new features, breaking enhancements, and any other code that the core development team may be working on. I'm not actually sure what this means. I fear that it may be motivated by an inaccurate assessment of the current situation. The existing instability comes almost entirely from Phobos, not from the compiler. Historically there have been very few instances where you might want to choose an older compiler in preference to the latest release. As I've said before, the one time when a language change caused *massive* instability was in the attempt to move AAs from language to library -- even though that wasn't even supposed to affect existing code in any way. The other thing that typically causes regressions is fixes to forward-reference bugs. Historically, addition of new language features has NOT caused instability. What has been true is that features have been added to the compiler before they were really usable, but they have not broken existing code. Fairly obviously the 64 bit compiler was quite buggy when initially released. But even that massive change wasn't much more buggy than the library AAs! So I am not sure that you can correctly guess where instability will come from. In summary -- I would not expect your stable DMD to be very different from the normal DMD. Phobos is where the instability issue is. There are three issues we are trying to address: The first and largest issue is the long and variable periods between DMD releases. By the end of the 2.060 Beta period there will have been at least 3.5 months since 2.059. And while for the people who can use Git HEAD this may not be a problem, there are MANY who, for whatever reason, must use the released versions. For them the 314 resolved issues and dozens of regressions fixed are a tantalizingly out of reach. I agree, but the fact that has happened, is just plain silly. There is no sensible reason why this happened. We were in fact ready for a release nearly two months ago. Somehow it did not happen. That ridiculous situation is the thing that needs to be addressed, IMHO. In fact, I see no reason why we couldn't do a release every month. The second issue is the root of the first. Much of the delay was caused by Walter starting to work on COFF. Which brings up the second point of contention in the community, a significant number of bugs are typically introduced when this new work is introduced precisely because it's not ready, I do not believe that at all. Where is the evidence for it? The third is the result of the first two. The slow release cadence combined with the requirement to push new features along side bug-fixes is seriously holding back the growth of the D community. There is a feeling out here that D is lurching unsteadily forward when it should be smoothly accelerating and most of this feeling is rooted in the prior two causes. This has a very corrosive effect on the community and particularly their willingness to contribute. The goal of dlang-stable is to provide the primary development team (you!) with the ability to release whenever you feel a new feature or enhancement is stable enough to be released WITHOUT having to worry about the ever growing number of bugfixes that are backlogged in with the new features. We are trying to reduce the bugfix pressure so that you can focus on delivering high-quality code when it's ready. The community WANTS these new features, but we CAN'T wait 3.5 months (or more!) for the bugfixes that are baked in with them. We have to provide BOTH. We don't need this complexity. The solution is *trivial*. We just need to decide in advance that we will target a release every X weeks, and that it should be delayed only for reasons of stability. An agreement is ALL that is required. But despite repeated requests, I have never been able to get any traction on the idea. Instead, people propose all kinds of crazy technical solutions, the most recent ones being changes to bugzilla, trello, and now dlang-stable. If we say, "There will be a new compiler release every 8 weeks", the problem is solved. Seriously. That one-off agreement is ALL that is required. But the D community finds it easier to implement a new 64-bit Windows compiler, than to make a agreement on a short-term release schedule. We're a strange bunch, I tell you.
Re: Coming Soon: Stable D Releases!
On 2012-07-25 09:43, Don Clugston wrote: We don't need this complexity. The solution is *trivial*. We just need to decide in advance that we will target a release every X weeks, and that it should be delayed only for reasons of stability. Yeah, but what happens when Walter or someone else decides to start a big project, i.e. implementing COFF support, a week before release? We end up with a bunch of half finished things. A solution to this would be to create a new branch or not push the changes upstream. Although I don't understand why Walter doesn't already do this. An agreement is ALL that is required. But despite repeated requests, I have never been able to get any traction on the idea. Instead, people propose all kinds of crazy technical solutions, the most recent ones being changes to bugzilla, trello, and now dlang-stable. If we say, "There will be a new compiler release every 8 weeks", the problem is solved. Seriously. That one-off agreement is ALL that is required. Apparently it seems very difficult to agree upon, since it hasn't happened. The releases just pop up at random. -- /Jacob Carlborg
Re: Coming Soon: Stable D Releases!
On 25/07/12 14:32, Jacob Carlborg wrote: On 2012-07-25 09:43, Don Clugston wrote: We don't need this complexity. The solution is *trivial*. We just need to decide in advance that we will target a release every X weeks, and that it should be delayed only for reasons of stability. Yeah, but what happens when Walter or someone else decides to start a big project, i.e. implementing COFF support, a week before release? We end up with a bunch of half finished things. If we had an agreed release cycle, it would not happen. The release cycle would be a higher authority than any single person, even Walter. A solution to this would be to create a new branch or not push the changes upstream. Although I don't understand why Walter doesn't already do this. An agreement is ALL that is required. But despite repeated requests, I have never been able to get any traction on the idea. Instead, people propose all kinds of crazy technical solutions, the most recent ones being changes to bugzilla, trello, and now dlang-stable. If we say, "There will be a new compiler release every 8 weeks", the problem is solved. Seriously. That one-off agreement is ALL that is required. Apparently it seems very difficult to agree upon, since it hasn't happened. The releases just pop up at random. I have tried many times, without success. I've never succeeded in getting more than two or three people interested.
Re: Coming Soon: Stable D Releases!
On 2012-07-25 14:47, Don Clugston wrote: If we had an agreed release cycle, it would not happen. The release cycle would be a higher authority than any single person, even Walter. I don't think it's that simple. We would also need some kind of window when you're allowed to commit new things to the repository. This window could end one or two weeks before the release should be out. Otherwise people will think that just "their small commit" can be added just a day before the release day "since it won't cause any problems". -- /Jacob Carlborg
Re: Coming Soon: Stable D Releases!
Jacob Carlborg, el 25 de July a las 14:32 me escribiste: > On 2012-07-25 09:43, Don Clugston wrote: > > >We don't need this complexity. The solution is *trivial*. We just need > >to decide in advance that we will target a release every X weeks, and > >that it should be delayed only for reasons of stability. > > Yeah, but what happens when Walter or someone else decides to start > a big project, i.e. implementing COFF support, a week before > release? We end up with a bunch of half finished things. > > A solution to this would be to create a new branch or not push the > changes upstream. Although I don't understand why Walter doesn't > already do this. The same reason he is pushing "revert ..." patches all the time, he is using git as if it were svn :P -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Estoy de acuerdo en que el hombre es igual a los ojos de Dios..., pero hay algunos que, siendo negros, hacen uso de lo que no les corresponde. Eso Dios no lo ve. -- Ricardo Vaporeso. Manifestación en Mississippi a favor de los blancos, 1923.
Re: Coming Soon: Stable D Releases!
On Wed, 25 Jul 2012 00:43:23 -0700, Don Clugston wrote: On 24/07/12 19:27, Adam Wilson wrote: On Tue, 24 Jul 2012 01:50:02 -0700, Don Clugston wrote: On 16/07/12 09:51, Adam Wilson wrote: As a result of the D Versioning thread, we have decided to create a new organization on Github called dlang-stable. This organization will be responsible for maintaining stable releases of DMD, DRuntime, and Phobos. So what is a stable release? A stable release is a complete build of DMD, DRuntime, and Phobos that ONLY includes the latest bug-fixes and non-breaking enhancements to existing features. It will not include, new features, breaking enhancements, and any other code that the core development team may be working on. I'm not actually sure what this means. I fear that it may be motivated by an inaccurate assessment of the current situation. The existing instability comes almost entirely from Phobos, not from the compiler. Historically there have been very few instances where you might want to choose an older compiler in preference to the latest release. As I've said before, the one time when a language change caused *massive* instability was in the attempt to move AAs from language to library -- even though that wasn't even supposed to affect existing code in any way. The other thing that typically causes regressions is fixes to forward-reference bugs. Historically, addition of new language features has NOT caused instability. What has been true is that features have been added to the compiler before they were really usable, but they have not broken existing code. Fairly obviously the 64 bit compiler was quite buggy when initially released. But even that massive change wasn't much more buggy than the library AAs! So I am not sure that you can correctly guess where instability will come from. In summary -- I would not expect your stable DMD to be very different from the normal DMD. Phobos is where the instability issue is. There are three issues we are trying to address: The first and largest issue is the long and variable periods between DMD releases. By the end of the 2.060 Beta period there will have been at least 3.5 months since 2.059. And while for the people who can use Git HEAD this may not be a problem, there are MANY who, for whatever reason, must use the released versions. For them the 314 resolved issues and dozens of regressions fixed are a tantalizingly out of reach. I agree, but the fact that has happened, is just plain silly. There is no sensible reason why this happened. We were in fact ready for a release nearly two months ago. Somehow it did not happen. That ridiculous situation is the thing that needs to be addressed, IMHO. In fact, I see no reason why we couldn't do a release every month. The second issue is the root of the first. Much of the delay was caused by Walter starting to work on COFF. Which brings up the second point of contention in the community, a significant number of bugs are typically introduced when this new work is introduced precisely because it's not ready, I do not believe that at all. Where is the evidence for it? The third is the result of the first two. The slow release cadence combined with the requirement to push new features along side bug-fixes is seriously holding back the growth of the D community. There is a feeling out here that D is lurching unsteadily forward when it should be smoothly accelerating and most of this feeling is rooted in the prior two causes. This has a very corrosive effect on the community and particularly their willingness to contribute. The goal of dlang-stable is to provide the primary development team (you!) with the ability to release whenever you feel a new feature or enhancement is stable enough to be released WITHOUT having to worry about the ever growing number of bugfixes that are backlogged in with the new features. We are trying to reduce the bugfix pressure so that you can focus on delivering high-quality code when it's ready. The community WANTS these new features, but we CAN'T wait 3.5 months (or more!) for the bugfixes that are baked in with them. We have to provide BOTH. We don't need this complexity. The solution is *trivial*. We just need to decide in advance that we will target a release every X weeks, and that it should be delayed only for reasons of stability. An agreement is ALL that is required. But despite repeated requests, I have never been able to get any traction on the idea. Instead, people propose all kinds of crazy technical solutions, the most recent ones being changes to bugzilla, trello, and now dlang-stable. If we say, "There will be a new compiler release every 8 weeks", the problem is solved. Seriously. That one-off agreement is ALL that is required. But the D community finds it easier to implement a new 64-bit Windows compiler, than to make a agreement on a short-term release schedule. We're a strange bunch, I tell you. I don't think a rigid re
Re: Coming Soon: Stable D Releases!
Jacob Carlborg, el 25 de July a las 17:08 me escribiste: > On 2012-07-25 14:47, Don Clugston wrote: > > >If we had an agreed release cycle, it would not happen. The release > >cycle would be a higher authority than any single person, even Walter. > > I don't think it's that simple. We would also need some kind of > window when you're allowed to commit new things to the repository. Like Linux's "merge window". It's simple, you accept new features just for a short period of time, and then just work on stabilizing things and bug fixing. That said, I wish D never include new features (as a language) unless there is a stable branch, which is still maintained for some time and don't get them. Bare in mind that DMD != D Programming Language, so adding new features to DMD is perfectly fine for me, like COFF or a new architecture. As long as it doesn't break old code is fine. > This window could end one or two weeks before the release should be > out. Otherwise people will think that just "their small commit" can > be added just a day before the release day "since it won't cause any > problems". The window doesn't need to be too long, you can always develop new features in parallel in your own branch while a release is being stabilized. You don't have to wait for the merge window to open to develop new features, is just a *merge* window, when it's open you're new feature should be done already, the window is only there to say "hey! Please pull from this branch!". If you want a monthly release, I'd say a 1 week merge window is enough (leaves you with 3 weeks for stabilization). -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Estoy en berlin Es como palermo Pero Mas copado Muuucho menos careta
Re: Coming Soon: Stable D Releases!
On 2012-07-25 19:17, Leandro Lucarella wrote: Like Linux's "merge window". It's simple, you accept new features just for a short period of time, and then just work on stabilizing things and bug fixing. Yes, exactly. That said, I wish D never include new features (as a language) unless there is a stable branch, which is still maintained for some time and don't get them. I don't mind new features once in a while, if it's done correctly. Bare in mind that DMD != D Programming Language, so adding new features to DMD is perfectly fine for me, like COFF or a new architecture. As long as it doesn't break old code is fine. I agree. That is another, slightly related problem with D. Currently, D programming language == DMD == Druntime == Phobos. They're all to closely connected. There should be possible to just to a release of Phobos, for example. Or a release of DMD with just bug fixes. The window doesn't need to be too long, you can always develop new features in parallel in your own branch while a release is being stabilized. You don't have to wait for the merge window to open to develop new features, is just a *merge* window, when it's open you're new feature should be done already, the window is only there to say "hey! Please pull from this branch!". Exactly. If you want a monthly release, I'd say a 1 week merge window is enough (leaves you with 3 weeks for stabilization). Yes, the merge window depends on how often we release. -- /Jacob Carlborg
Re: Coming Soon: Stable D Releases!
On 2012-07-25 19:08, Leandro Lucarella wrote: The same reason he is pushing "revert ..." patches all the time, he is using git as if it were svn :P I'm suspecting that. -- /Jacob Carlborg
Re: Coming Soon: Stable D Releases!
I don't think a rigid release schedule has ever worked in software development. Linus is world-renowned for releasing at what looks like utterly random intervals and I know of very little software that ships on a strict time based cadence. It almost ALWAYS slips for some reason or the other. I guess my point is that it isn't as easy as making the schedule the final arbiter because it is an attempt to deny that the real world exists. What if Walter is on vacation (I don't know if he believes in vacations but, bear with me) during release week? What then? Do we demand that he organize is life around our precious release schedule? You can at least come to an official agreement that we should release on a given interval. Then we don't need to stop the world to make that happened. Sometimes it will be delayed and that would be acceptable. If we do have a release schedule and Walter, for example, knows he will be on vacation during the release week. We can plan ahead and annoyance that the next release will be delayed or skipped. Also, what about projects that absolutely cannot be completed in under X weeks? Do we just leave the code in the release, half working, waiting to spread all KINDS of bugs? No, no, no. That's another problem. Don't commit anything to upstream/master that isn't finished. I don't know why Walter does that. Does he not have his own fork? Why not create a new branch at least? That sounds to almost everyone here like a recipe for complete disaster. More to the point, I know of no successful project, OSS or Commercial, that follows this model. Development and Stable releases are a staple of the Open-Source world, and it would behoove us to learn from those who went before us. If the model doesn't work, why is it nearly universal? Do we really think that we are better than Linux or LibreOffice or Java? I would make an argument that such thinking is one of the things holding D back. The industry is crying out for something like D ... just look at the proliferation of new native languages that attempt to address the problems of C/C++ in their own ways; and yet, D, with it's clean syntax and multi-paradigm capabilities is a bit player. If I had my way, this would all be handled by the dev team via Git branching. But it appears that Walter was unwilling to do the work, so we the community have stepped up. It is an entirely predictable outcome of the very real pains felt in the community. And dlang-stable is essentially a branch of the HEAD repos, just with more process in between. Less efficient, certainly. Will it fail ... I doubt it, but let's find out. And seriously, the flexibility to release whenever and not be pressured by the community at large because we've gone so long with bugfixes should be freeing to the dev team, not constricting! As a side note, 64-bit support is critical to the long term viability of D. 32-bit is a rapidly dying concern, once ARM 64-bit goes mainstream the party is over. 32-bit will be archaic by the end of the decade, and out of common usage well before then. Agree. -- /Jacob Carlborg
Re: Coming Soon: Stable D Releases!
On Thursday, July 26, 2012 08:35:26 Jacob Carlborg wrote: > > I don't think a rigid release schedule has ever worked in software > > development. Linus is world-renowned for releasing at what looks like > > utterly random intervals and I know of very little software that ships > > on a strict time based cadence. It almost ALWAYS slips for some reason > > or the other. > > > > I guess my point is that it isn't as easy as making the schedule the > > final arbiter because it is an attempt to deny that the real world > > exists. What if Walter is on vacation (I don't know if he believes in > > vacations but, bear with me) during release week? What then? Do we > > demand that he organize is life around our precious release schedule? > > You can at least come to an official agreement that we should release on > a given interval. Then we don't need to stop the world to make that > happened. Sometimes it will be delayed and that would be acceptable. If > we do have a release schedule and Walter, for example, knows he will be > on vacation during the release week. We can plan ahead and annoyance > that the next release will be delayed or skipped. > > > Also, what about projects that absolutely cannot be completed in under X > > weeks? Do we just leave the code in the release, half working, waiting > > to spread all KINDS of bugs? > > No, no, no. That's another problem. Don't commit anything to > upstream/master that isn't finished. I don't know why Walter does that. > Does he not have his own fork? Why not create a new branch at least? There are a number of things that we could do to improve our release process - a number of them revolving around taking proper advantage of git (though not all) - but actually effecting those kind of changes has been incredibly difficult as Don has pointed out. So, while there are a number of things that we _could_ do (and probably _should_ do), the fact that Walter has agreed to this scheme with dlang-stable is actually _huge_. It may help open the door to other changes to the release process (like branching for a beta). AFAIK, Walter never branches for _anything_, though maybe he does have branches of some kind on his computer. - Jonathan M Davis
Re: Coming Soon: Stable D Releases!
On 2012-07-26 08:47, Jonathan M Davis wrote: There are a number of things that we could do to improve our release process - a number of them revolving around taking proper advantage of git (though not all) - but actually effecting those kind of changes has been incredibly difficult as Don has pointed out. So, while there are a number of things that we _could_ do (and probably _should_ do), the fact that Walter has agreed to this scheme with dlang-stable is actually _huge_. It may help open the door to other changes to the release process (like branching for a beta). AFAIK, Walter never branches for _anything_, though maybe he does have branches of some kind on his computer. Yeah, hopefully it will open the door for more changes. -- /Jacob Carlborg
